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1 .  INTRODUCTION 

i 

1.1  \  HOS  IS  A  SOLUTION  TO  A  SYSTEM  EVALUATION  PROBLEM 

\  , 

-A  In  recent  years,  as  "systems'  (whether  spacecraft,  jet  fighters, 
or  office  equipment)  have  become  more  complex,  there  has  been  a  growing 
concern  about  the  extent  to  which  these  systems  are  adapted  to  the  capa¬ 
bilities  of  the  individuals  who  are  called  on  to  operate  therM  One  of  the 
primary  emphases  in  the  field  of  human  factors  engineering  has  been  on 
developing  methodologies  to  evaluate  systems  to  ensure  that  they  are  as 
well  adapted  as  possible  to  human  capabilities  and  limitations.  A  major 
thrust  in  these  efforts  has  been  to  develop  methods  that  would  enable  the 
operability  of  a  system  to  be  evaluated  before  the  system  is  ever  built. 
Typically,  this  has  been  done  by  building  prototypes  or  simulators  which  are 
"flown"  with  an  operator  "in-the-loop."  The  operator's  performance  is  then 
measured  and  judged  against  a  set  of  performance  criteria.  The  measures, 
along  with  the  operator's  comments  are  used  intuitively  to  "select"  changes 
that  are  intended  to  improve  system  performance.  Thus.^yie  methodology 
currently  used  to  evaluate  systems  —  building  prototypes  or  testing  designs 
in  simulators  —  relies  on  the  construction  of  real  hardware  that  can  be 
tested  with  real  operators.  This  requirement  inevitably  means  that  there 
is  a  substantial  time  lag  between  the  system's  initial  design  and  the  time 
when  the  prototype  can  be  built,  tested,  evaluated,  and  any  proposed  changes 
"recycled"  through  the  system  design  process.  In  addition,  the  use  of  dynamic 
simulators  that  use  real  operators  inevitably  requires  a  substantial  outlay 
of  money  for  the  development  of  attendant  hardware  and  software,  for  the 
training  and  retraining  of  operators,  and  for  the  performance,  analysis,  and 
evaluation  of  controlled  experiments  that  utilize  the  simulators.-^  Consequently, 
while  dynamic  simulators  can  be  highly  useful  in  training  operators,  it  is 
doubtful  that  the  data  collected  from  them  has  a  significant  impact  on  system 
design. 


HOS  WAS  DEVELOPED  TO  ENABLE  SYSTEMS  TO  BE  EVALUATED 


•  EARLY  IN  DESIGN  PROCESS 

•  WITH  MAN-IN'THE-LOOP 

•  WITHOUT  HAVING  TO  BUILD  HARDWARE  OR 
SOFTWARE 

•  IN  A  WAY  THAT  WOULD  ENSURE  CONSISTENT, 
COMPARABLE,  AND  REPRODUCIBLE  RESULTS 
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"The  Human  Operator  Simulator  (HOS)  was  developed  to  alleviate 
these  problems  in  two  ways.  First,  by  enabling  potential  problem  areas  to 
be  identified  earlier  in  the  system  design  process,  HOS  enables  corrections 
to  be  made  at  lower  cost  and  with  less  disruption  of  development  schedules. 
Second,  for  areas  of  marginal  operator  performance,  HOS  can  focus  dynamic 
simulations  on  the  likely  sources  of  difficulty,  reducing  the  time  and  cost 
required  to  validate  system  operability.  _ _ 

As  soon  as  the  definition  of  the  functional  requirements  and  the 
allocation  of  functions  are  completed,  a  HOS  simulation  can  be  developed 
that  will  describe  both  the  hardware  and  the  procedures  that  the  operator 
is  to  use  in  order  to  control  a  proposed  piece  of  equipment.  These  descrip¬ 
tions  are  then  combined  with  a  “problem  description"  that  defines  the  opera¬ 
tor's  environment  and  HOS  then  simulates  the  system  as  if  it  were  a  real 
operator  using  a  real  piece  of  equipment  with  a  real  job  to  do  and  a  real 
problem  to  solve. 

Unlike  other  “operator  simulators"  that  simply  draw  times  for  task 
executions  from  sample  distributions,  HOS  is  a  detailed  model  of  an  operator. 
The  HOS  operator  has  eyes ,  hands,  and  feet  that  move,  absorb  information 
from  displays,  and  manipulate  controls  in  accordance  with  the  analyst's 
instructions.  HOS  has  a  mind  that  can  perform  mental  calculations  that 
remembers  and  forgets  information.  The  HOS  operator  will  perform  the  actions 
that  are  necessary  in  order  to  accomplish  a  task,  but  will  omit  actions  that 
may  be  unnecessary  because  of  the  situation  in  which  the  operator  finds 
himsel f. 

1.2  WHAT  INFORMATION  CAN  BE  OBTAINED  BY  SIMULATING  AN  OPERATOR? 

First,  HOS  enables  an  analyst  to  perform  operator-in-the  loop 
"experiments"  that  produce  consistent,  comparable,  and  reproducible  results. 
This  is  important  because  one  of  the  major  problems  that  plagues  human  per¬ 
formance  experimentation  is  the  difficulty  of  providing  proper  controls  on 
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ADVANTAGES  OF  SIMULATION 


OPERATOR  CHARACTERISTICS  AND 
TASKS  CAN  BE  CONTROLLED 


ENVIRONMENTAL  CONDITIONS  AND 
PROBLEM  SITUATIONS  CAN  BE 
CONTROLLED 


PROCESSES  CAN  BE  OBSERVED, 
MEASURED,  AND  RECORDED  WITHOUT 
INTERFERRING  WITH  PERFORMANCE 
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all  the  potentially  relevant  experimental  factors.  Variability  in  the  ways 
in  which  operators  may  choose  to  carry  out  tasks  in  a  particular  situation 
often  makes  it  difficult  to  compare  the  results  obtained  on  different 
experimental  trials.  Clearly,  there  is  much  information  to  be  learned  by 
observing  the  full  range  of  performance.  However,  in  order  to  be  able  to 
ensure  a  fair  evaluation  of  a  proposed  system,  one  would  prefer  to  have 
consistent  average  performance.  HOS  gives  the  analyst  the  ability  to 
experiment  with  an  operator  whose  performance  is  guaranteed  to  be  consistent 
and  typical. 

At  the  same  time,  HOS  permits  experimentation  to  be  performed 
with  operators  who  deviate  from  the  average  in  a  variety  of  ways.  The  HOS 
operator  is,  theoretically,  a  trained  operator  of  coverage  capabilities  who 
will  carry  out  his  instructions  exactly  as  he  is  told  to  do,  exhibiting 
some  variability  in  performance  speed,  but,  in  the  long  run,  taking  the 
amount  of  time  for  each  instruction  that  an  average  operator  would  have 
taken.  However,  by  suitably  changing  some  of  the  parameters,  equations, 
or  instructions  in  the  simulation,  an  analyst  can  change  the  HOS  operator 
into  a  highly  idiosyncratic  individual. 

The  second  advantage  that  is  gained  by  having  the  ability  to 
simulate  a  human  operator  is  that  one  can  readily  simulate  different  environ¬ 
mental  conditions  to  examine  how  the  operator  responds  to  changing  situations. 
For  example,  one  HOS  simulation  (Ref.  1)  examined  the  performance  of  the 
Sensor  Station  3  operator  on  board  the  P-3C  ASW  Patrol  Aircraft  during  a 
simulated  anchorage  mission  in  the  Mediterranean.  Because  it  was  a  simula¬ 
tion,  all  the  features  of  the  problem  environment  could  be  controlled  — 
the  numbers  and  types  of  targets,  their  locations  and  characteristics, 
emitter  duty  cycles,  tactics,  etc.  The  effects  on  the  operator's  performance 
when  more  targets  were  added  to  the  search  area  could  be  readily  examined 
and  the  conditions  under  which  the  operator  became  overloaded  could  be 
determined.  In  another  simulation  (Ref.  2),  the  HOS  operator  performed 
a  tracking  task  and  an  interfering  secondary  task  simultaneously.  The 
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effects  of  varying  the  characteristics  of  the  signal  that  the  operator 
was  tracking  and  the  frequency  and  duration  of  the  Interrupts  caused  by 
the  secondary  task  could  be  studied  under  more  precisely  controlled  con¬ 
ditions  than  would  be  achievable  in  the  laboratory. 

A  third  important  advantage  of  simulation  over  live  experimenta¬ 
tion  lies  in  the  fact  that  a  simulated  process  can  be  observed,  measured, 
and  recorded  with  perfect  fidelity  without  any  danger  of  having  the  observa¬ 
tion  process  disturb  the  performance  being  observed.  In  live  experiments, 
the  performance  of  human  subjects  is  always  affected  by  the  human's  aware- 
-  ness  that  he  is  being  observed.  In  some  cases,  the  observation  and  measure¬ 
ment  apparatus  may  actually  restrict  the  subject's  sensory  and  motor  capa¬ 
bilities.  In  all  cases,  the  experimental  subject  who  knows  that  he  is 
participating  In  an  experiment  will  behave  more  cautiously  and  deliberately 
than  a  person  who  does  not  believe  that  he  is  being  studied.  A  simulated 
human  operator,  on  the  other  hand,  will  never  modify  his  performance 
because  he  suspects  that  someone  Is  watching. 

1.3  CHARACTERISTICS  OF  THE  HOS  OPERATOR 

The  HOS  operator  is  a  trained  operator  —  i.e. ,  an  operator  who 
is  familiar  with  the  equipment  (I.e.,  knows  the  locations  of  all  the  displays 
and  controls  and  their  characteristics),  and  how  to  operate  it  (i.e.,  knows 
the  procedures  and  mental  calculations  that  must  be  performed).  Since  the 
operator  Is  assumed  to  be  trained,  the  operator  will  carry  out  the  procedures 
and  use  the  equipment  unerringly.  The  operator  will  never  perform  an  instruc¬ 
tion  out  of  sequence  or  other  than  Instructed. 

This  does  not  mean,  however,  that  the  operator  cannot  make  a 
mistake.  There  are  at  least  two  sources  of  error  in  the  HOS  operator’s 
performance  —  his  short-term  memory  and  his  perceptual  processes.*  When 


•There  is  actually  a  third  source  —  the  operator  could  have  been 
trained  incorrectly,  causing  him  to  do  things  in  the  wrong  sequence. 
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THE  HOS  OPERATOR 


•  A  TRAINED  OPERATOR 

—  KNOWS  LOCATIONS  OF  DISPLAYS 
AND  CONTROLS 
—  KNOWS  PROCEDURES 
—  KNOWS  MENTAL  CALCULATION 

PRnrPPPPP 

--  WILL  NOT  PERFORM  INSTRUC¬ 
TIONS  OUT  OF  SEQUENCE  OR 
OTHER  THAN  INSTRUCTED 


•  ERRORS  ARE  THE  RESULT  OF  OPERATOR/ 
EQUIPMENT  LIMITATIONS 

—  "FALLIBLE"  SHORT-TERM  MEMORY 
—  PERCEPTUAL/MOTOR  PROCESSES  CAN 
CAUSE  ERRORS  IF  DISPLAYS  ARE  HARD 
TO  READ  OR  CONTROLS  ARE  HARD  TO 
MANIPULATE 
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HOS  REQUIRES  DATA  ON 

•  DISPLAY  AND  CONTROL  LOCATIONS 

•  DISPLAY  AND  CONTROL  CHARACTERISTICS 

•  HOW  EACH  DISPLAY  AND  CONTROL  IS  USED 

•  OPERATOR'S  MISSION 

•  OPERATOR  CHARACTERISTICS 

•  SPECIFIC  PROBLEM  ENVIRONMENT 
f  ENVIRONMENTAL/SYSTEM  DYNAMICS 
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the  operator  is  told  (or  decides)  to  read  a  display,  for  example,  he  may 
read  it  incorrectly,  either  because  of  some  characteristic  of  the  display 
or  because  he  did  not  spend  a  sufficient  amount  of  time  reading  the  display. 
When  attempting  to  remember  a  value,  the  operator  might  remember  the  value 
incorrectly.  These  errors  can  cascade  down  through  the  rest  of  the  simula¬ 
tion.  But,  as  modeled  by  HOS,  they  represent  realistic  possibilities  that 

might  occur  if  a  real  operator  were  performing  the  same  job  with  the  same 

equipment.  We  will  be  saying  more  about  the  sources  of  operator  error 
when  we  discuss  the  individual  performance  models  In  HOS. 

1.4  WHAT  INFORMATION  POES  HOS  REQUIRE? 

Suppose  that  we  wish  to  simulate  a  pilot  in  a  proposed  aircraft 
cockpit  in  order  to  evaluate  the  cockpit  design.  HOS  would  need  a  detailed 
description  of: 

•  The  location  of  each  display  and  control  in  the  proposed 
cockpit. 

•  The  characteristics  of  each  display  and  control. 

•  How  the  pilot  uses  each  display  and  control  to  fly  the  air¬ 

craft  —  e.g.,  how  the  displays  and  controls  are  used  when 
taxiing,  taking  off,  climbing,  etc. 

•  Specific  environmental  conditions  at  the  beginning  of  the 
problem  —  e.g.,  the  plane's  altitude,  airspeed,  windspeed, 
etc. 

t  The  pilot's  task  (mission)  —  e.g.,  land  the  plane. 

t  The  aircraft's  flight  characteristics. 

HOS  can  then  simulate  both  the  performance  of  the  operator  and 
the  aircraft  as  the  operator  carries  out  his  job.  Some  of  his  information 
can  be  omitted  or  treated  as  a  constant  value;  how  this  works  will  be 
explained  later. 
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A  HOS  SIMULATION  REQUIRES  DESCRIPTIONS  OF 


•  HOW  THE  SYSTEM  IS  CONFIGURED 

•  HOW  THE  SYSTEM  FUNCTIONS 

•  HOW  THE  OPERATOR  USES  IT 


OPERATOR  ACTIONS 
OPERATOR  DECISIONS 


Clearly,  there  is  a  lot  of  information  that  must  be  supplied  to 
HOS.  Preparing  this  information  is  not,  admittedly,  an  easy  job.  When 
creating  a  HOS  simulation,  one  generally  has  to  search  through  many  references 
accumulating  scattered  information  about  how  each  system  component  functions 
until  a  coherent  pattern  emerges  as  to  how  the  system,  as  a  whole,  is  con¬ 
figured,  how  it  functions,  and  how  the  operator  uses  It.  It  is  this  last 
point  —  how  the  operator  uses  the  system  —  that  tends  to  be  the  stickiest 
point  to  tease  out  from  available  references.  Typically,  most  systems 
operations  manuals  will  describe  what  the  operator  must  do  in  order  to 
perform  a  function,  but  do  not  describe  what  must  be  done  in  order  to  solve 
a  problem.  For  example.  Naval  operations  manuals  discuss  in  detail  what 
an  ASW  acoustic  sensor  station  operator  must  do  in  order  to  enter  a  fix  that 
he  obtains  from  his  sonobuoys,  but  they  do  not  describe  the  decisions  that 
the  operator  must  make,  almost  intuitively,  in  order  to  obtain  the  fix  in 
the  first  place.  These  decisions  include  such  things  as  deciding  how  many 
sensors  to  place,  where  and  when  to  place  them,  what  channels  to  listen  to 
and  when  to  listen,  etc.  These  types  of  decisions  are  rarely  elaborated 
upon  in  any  standard  manuals,  but  they  are  the  sorts  of  decisions  that  a 
real  operator  must  make.  Clearly,  in  a  system  that  is  still  on  the  drawing 
boards,  this  information  is  even  harder  to  obtain.  But  teasing  this  Informa¬ 
tion  out  of  system  designers  is  one  of  the  real  benefits  that  we  feel  HOS 
provides  —  HOS  forces  system  designers  to  think  about  what  they  are  asking 
an  operator  to  do  and  why  and  it  requires  that  they  put  these  operator 
task  specifications  down  on  paper.  These  operator  specifications  are  just 
as  important  as  hardware  and  software  specifications  to  the  overall  specifica¬ 
tion  of  the  system,  but  have  all  too  frequently  been  ignored  in  the  past. 

1.5  HOS  IS  A  COMPOSITE  OF  OPERATOR  PERFORMANCE  MODELS 

In  this  guide,  we  will  be  demonstrating  how  one  develops  these 
operator  task  specifications  for  a  simple  problem  and  how  the  specifications 
are  converted  to  the  instructions  that  HOS  is  to  follow.  But,  first,  there  is 
a  more  basic  question  that  we  must  answer  —  how  will  HOS  actually  carry  out 
these  instructions,  i.e.,  what  is  the  underlying  model  of  the  human  operator 
that  is  incorporated  into  HOS? 
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H05  IS  A  COMPOSITE  OF  OPERATOR  PERFORMANCE 
DERIVED  FROM  SELECTED  HUMAN  PERFORMANCE 
LITERATURE, 


MODELS  ARE  ABLE  TO  BE  CHANGED  READILY 
WITH  ADVANCES  IN  THE  STATE-OF-THE-ART, 


HOS  IS  BEING  VALIDATED  BY  COMPARING 
RESULTS  WITH  OBSERVED  PERFORMANCE. 
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The  answer  to  this  question  is  that  HOS  is,  in  fact,  a  composite 
of  a  number  of  different  models  of  human  performance.*  The  HOS  program  has 
been  written  in  such  a  way  that  any  one  of  these  models  can  be  changed 
fairly  easily,  as  the  state-of-the-art  of  human  performance  modeling  changes. 

In  this  course,  we  will  be  describing  the  performance  models  as  they  cur¬ 
rently  exist  in  the  program  and,  in  addition,  we  will  indicate  what  studies 
these  models  have  been  derived  from.  You  may  find  that  you  disagree  with  the 
appropriateness  of  a  particular  model  in  particular  situations  or  the  relevance 
of  the  experiments  on  which  the  model  is  based  to  the  problems  to  which  it 
is  being  applied.  Feel  free  to  do  so.  We  have  simply  selected  a  set  of 
models  and  experiments  that  we  felt  best  represents  the  current  state  of 
operator  performance  modeling  for  the  types  of  problems  we  are  dealing 
with.  HOS  can  be  adapted  to  accommodate  other  alternative  formulations  if 
these  seem  more  appropriate.  There  were  many  situations  in  which  sifficient 
data  were  unavailable  to  ensure  the  validity  of  a  given  model,  as  formulated 
in  HOS.  Thus,  we  cannot  be  certain  that  all  the  submodels  in  HOS  are  as 
valid  as  we  hope  they  are.  Rather  than  waiting  until  sufficient  data  might 
be  collected  or  until  others  formulate  models  which  could  be  generally 
accepted,  we  chose  instead  to  get  HOS  into  operation  and  then  adapt  and 
improve  it  as  it  becomes  necessary,  by  comparing  its  results  with  observations 
of  the  performance  of  real  human  operators. 

1.6  HOS  PRIMITIVE  FUNCTIONS 

HOS  considers  the  operator  to  be  capable  of  performing  seven 
primitive  functions: 

(1)  Obtaining  information. 

(2)  Remembering  information. 


*Note  that  the 
must  follow  is  also 
equipment  should  be 
use  the  equipment. 


analyst's  description  of  the  procedures  the  operator 
a  model  —  a  model  of  how  the  analyst  believes  that  the 
operated  and/or  a  model  of  how  an  operator  will,  in  fact. 
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HOS  PRIMITIVE  FUNCTIONS 

•  INFORMATION  ABSORPTION 

•  INFORMATION  RECALL 
•  » 

•  MENTAL  COMPUTATION 

•  DECISION-MAKING 

•  ANATOMY  MOVEMENT 

•  CONTROL-MANIPULATION 

•  RELAXATION 
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IT 


(3) 

Performing  a  mental 

computation. 

(4) 

Making  a  decision. 

(5) 

Moving  a  body  part. 

(6) 

Performing  a  control 

manipulation 

(7) 

Relaxing. 

Every  action  that  the  HOS  operator  performs  is  a  combination  of 
one  or  more  of  these  primitive  functions.  Although  an  analyst  can  write 
operator  procedures  that  will  force  the  operator  to  perform  a  particular 
primitive  at  a  particular  point  in  a  sequence  of  actions,*  generally  the 
analyst  will  let  HOS  determine  the  primitives  required  to  accomplish  a 
particular  task  for  itself. 

The  primitive  functions  are  often  either  imbedded  in,  or  contain 
within  themselves,  human  performance  models.  For  example,  when  a  situation 
arises  in  which  the  operator  must  move  his  hand  to  a  particular  device,  there 
is  logic  that  determines  which  hand  he  will  use.  Similarly,  when  the  operator 
attempts  to  recall  some  item  of  information,  there  is  a  recall  model  that 
is  automatically  assessed  by  the  program  that  simulates  the  operator's  short¬ 
term  memory  processes.  Because  of  the  level  at  which  these  models  operate, 
we  often  refer  to  them  as  micro -models. 

1.7  THE  HUMAN  OPERATOR  PROCEDURES  (HOPROC)  LANGUAGE 

The  language  that  the  analyst  uses  to  describe  the  tasks  the 
operator  is  to  perform  is  called  HOPROC,  the  Human  Operator  Procedures 
Language.  HOPROC  enables  the  analyst  to  access  the  micro-models  directly 


*Note  that  we  did  not  say  "at  a  particular  point  in  time."  The  analyst 
has  some  control  over  the  time  at  which  the  operator  will  perform  each  action, 
but  not  much.  HOS  itself  determines  how  long  each  action  will  take  and  hence 
the  time  at  which  a  particular  action  will  take  place. 
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THE  HUMAN  OPERATOR  PROCEDURES  (HOPROC)  LANGUAGE 


AN  ENGLISH-LIKE  LANGUAGE  USED  TO  DESCRIBE  BOTH  THE  OPERATOR'S 
TASKS  ANH  THE  FUNCTIONING  OF  THE  HARDWARE 


ALLOWS  BOTH  IMPLICIT  AND  EXPLICIT  ACCESS  TO  THE  HOS  MICRO¬ 
MODELS 


HOPROC  INSTRUCTIONS  LOOK  LIKE  THE  INSTRUCTIONS  THAT  WOULD  BE 
GIVEN  TO  REAL  OPERATORS 


CAN  BE  THE  BASIS  FOR  SYSTEMS  DOCUMENTATION  AND  TRAINING 


-  ^ 


to  describe  how  the  operator  is  to  perform  his  tasks.  More  commonly,  how¬ 
ever,  the  analyst  simply  describes  through  HOPROC  the  tasks  that  the  operator 
is  to  perform.  HOS  itself  will  then  determine  which  micro-models  are  needed 
in  order  to  accomplish  specific  functions.  Thus,  HOS  is  like  a  real 
operator  —  given  a  set  of  instructions  (in  HOPROC),  it  can  determine  for 
itself  what  actions  are  required  in  order  to  carry  out  the  instructions. 

As  we  shall  show  in  the  next  sections,  the  HOPROC  instructions  themselves 
look  very  much  like  the  instructions  that  would  be  given  to  a  real  operator. 
Thus,  the  HOPROC  procedures  developed  for  an  operator  station  could  serve 
as  the  basis  for  the  materials  to  train  operators  in  the  use  of  the  system, 
in  addition,  portions  of  HOPROC  describe  the  functions  of  the  hardware  and 
software  in  the  crewstation.  Thus,  in  addition  to  documenting  operator 
functions  within  the  crewstation,  the  HOPROC  description  of  a  crewstation 
provides  complete  documentation  on  the  crewstation  itself. 

1.8  A  SAMPLE  HOS  SIMULATION 

The  sample  simulation  that  we  will  be  using  in  this  course  is 
an  analysis  of  one  of  the  tasks  performed  by  the  P-3C  Sensor  Station  3  (SS-3) 
operator.  Specifically,  we  will  develop  a  simplified  version  of  the  operator's 
radar  plotting  procedures.  In  developing  the  simulation,  we  will  describe  all 
the  major  HOPROC  language  constructs  and  how  one  combines  them  into  a 
description  of  the  operator's  tasks.  Then  we  will  run  the  problem  through 
HOS,  examine  the  outputs  obtained  at  each  phase,  and  discuss  what  can  be 
learned  from  them  about  the  operator's  performance. 

By  way  of  an  introduction,  the  following  sections  describe  the 
SS-3  crewstation,  the  functions  of  the  SS-3  controls,  and  the  procedures 
that  the  operator  must  follow  when  plotting  radar  targets.  These  descrip¬ 
tions  are  then  followed  by  examples  of  the  outputs  obtained  by  running  HOS 
for  a  specific  set  of  targets.  Later  in  this  guide,  we  will  discuss  both 
the  inputs  and  outputs  in  more  detail. 
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In  the  discussion  that  follows,  the  names  that  will  be  given  to 
specific  displays  and  controls  in  the  operator's  crewstation  are  shown  in 
capital  letters. 

1.8.1  The  SS-3  Operator  Station 

Figure  1  shows  the  SS-3  operator  station  on  the  P-3C.  The  pri¬ 
mary  display  used  by  the  operator  is  the  multipurpose  digital  display  (the 
RADAR-DISPLAY)  on  which  both  tactical  symbology  and  raw  radar  data  can  be 
displayed.  The  controls  that  will  be  used  are  the  TRACK-BALL  and  some 
momentary  contact  switches  on  the  keyset  tray  —  the  RADAR-MODE  switch,  the 
FIOOK-VERIFY  switch,  and  the  ENTER-RADAR-CONTACT  switch  —  and  a  switch  that 
is  located  on  the  Radar  Control  Panel,  the  LOAD  switch. 

1.8.2  Functions  of  the  SS-3  Controls 

If  we  assume  that  the  radar  equipment  has  been  powered  up  and  is 
functioning  properly,  then,  when  the  operator  depresses  the  RADAR-MODE 
switch,  the  system  will  light  up  a  set  of  controls  (the  radar  matrix)  that 
indicates  the  subfunctions  available  to  the  operator.  These  controls  permit 
the  operator  to  perform  a  number  of  functions  related  to  the  processing 
radar  data.  We're  only  going  to  be  concerned  with  one  of  these  functions  — 
the  ENTER-RADAR-CONTACT  function  (Figure  2  ).  This  control  function  enables 
the  operator  to  enter  the  coordinates  of  a  radar  contact  to  the  onboard 
computer.  The  computer  will  automatically  assign  a  number  to  the  contact, 
record  the  time  at  which  the  contact  was  entered,  and  display  a  permament 
symbol  representing  the  contact  on  both  the  SS-3  operator's  display  and  on 
the  TACCO' s  display. 

But  in  order  to  enter  a  radar  contact,  the  operator  must  identify 
to  the  system  which  of  the  many  potential  contacts  he  is  interested  in.  He 
does  this  by  manipulating  a  TRACK-BALL  which  controls  the  position  of  a  cursor 
on  the  screen.  The  cursor  (the  HOOK)  appears  on  the  screen  as  a  small  circle. 
The  operator  must  manipulate  the  TRACK-BALL  until  the  HOOK  encircles  the 
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Figure  2.  Radar  matrix  function. 
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MISSION 

•  PERFORM  RADAR  PLOT 

—  ENABLE  THE  RADAR-DISPLAY 
—  SEARCH  FOR  AN  UNENTERED  CONTACT 
—  IF  ONE  IS  FOUND,  ENTER  IT  BY: 

(1)  MOVING  THE  HOOK  TO  THE  RADAR  CONTACT  POSITION 

(2)  DEPRESSING  HOOK-VERIFY 

(3)  ENABLE  THE  ENTER-RADAR-CONTACT  FUNCTION,  IF 
NECESSARY,  BY  DEPRESSING  RADAR-MODE 

(4)  DEPRESSING  ENTER-RADAR-CONTACT 
—  IF  NO  MORE  CAN  BE  FOUND,  END 
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the  particular  symbol  on  the  screen  that  he  is  interested  in.  Then,  when 
he  depresses  the  HOOK-VERIFY  pushbutton,  the  system  win  cause  the  encircled 
symbol  to  blink.  Any  action  that  the  operator  then  takes,  such  as  depressing 
the  ENTER-RADAR -CONTACT  pushbutton,  will  be  understood  by  the  system  to 
refer  to  the  hooked  symbol. 

One  issue  that  we  have  not  discussed  is  how  the  operator  powers 
up  the  radar  equipment  in  the  first  place.  For  our  purposes,  we  will  assume 
that  all  that  is  required  is  for  him  to  switch  the  LOAD  switch  from  its 
dumny  load  to  its  antenna  position  —  all  other  radar  initialization  actions 
will  be  assumed  to  have  been  performed  prior  to  the  start  of  the  simulation. 

1.8.3  Outline  of  Operator  Procedures 

We  can  now  outline  what  the  operator  is  required  to  do  in  order 
to  plot  a  set  of  radar  targets.  The  operator's  mission*  in  this  case,  is 
to  perform  a  radar  plot.  In  order  to  do  this,  the  operator  must  first 
enable  the  radar  matrix  by  depressing  the  radar  mode  pushbutton.  Then  he 
must  search  for  an  unentered  contact.  If  he  finds  one,  he  must  enter  it 
by  hooking  the  contact  and  depressing  ENTER -RADAR -CONTACT.  If  he  cannot 
find  any  more  unentered  contacts,  he  is  done. 

The  HOS  code  that  describes  this  mission  is  shown  in  Figure  3  . 

As  you  can  see,  there  is  a  close  correspondence  between  our  verbal  (outline) 
description  of  the  operator's  procedures  and  the  code  that  HOS  needs  in  order 
to  simulate  those  procedures. 

Examining  the  code,  we  see  that  HOS  requires  a  definition  of  the 
mission.  In  this  case,  the  mission  is  simply  to  perform  a  radar  plot, 
although  we  could  easily  have  added  additional  tasks  to  the  mission.  In  a 
normal  task  analysis,  we  might  simply  dig  through  some  references  at  this 
point  to  find  an  amount  of  time  that  we  would  use  as  the  average  amount  of 
time  required  to  perform?  a  radar  plot.  Alternatively,  we  might  pull  a 
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DEFINE  THE  “ISSION. 

*ERFORm  pahaR-plOT. 
End. 


DEFINE  The  PROCEDURE  TO  RaOAR-PLOT. 
enable  The  RAOAR-OISBLAY. 

IF  ANY  PADAP-CONTACT-STATuS  IS  NOT  ENTERED  Th£N 
FNTFB:  OESICiNATE  IT  AS  THE  RAOAR-CONTACT  OF  INTEREST; 

MOVE  The  HOOK-POSITION  TO  Th£ 

paoar-contact-position: 

DEPRESS  hOOK-vEPIFy: 

0E°PESS  ENTEP-PAOAH-CONTACT. 

IF  ANOTHER  PADAP-CONTACT-STATUS  IS  NOT  ENTERED 
THEN  GO  TO  ENTER  NOW. 

ENO. 


DEFINE  The  PROCEDURE  TO  ENABLE  Th£  paoaR-DISPLAY . 
turn  load  to  antenna. 

ENO. 


DEFINE  Th£  PROCEDURE  TO  ADJUST  Th£  hOOK-POSITION. 
CHECK:  READ  THE  hOOk-POSIT ION. 

IF  IT  IS  OK  THEN  ENO. 

DETERMINE  The  TRACK-BALL-POSITION. 

MOVE  THE  TRACK-BALL  to  The  RESULT. 

IF  THE  RATE  OF  THE  TRACK-BALL  IS  NOT  0,0  INCHES 
THEN  WAIT. 

GO  TO  CHECK  NOW. 


oefine  THE  PROCEDURE  TO  enable  hook-verify. 
AO JUST  THE  HOOK-POSITION. 

End. 


oefine  the  procedure  to  enable  enter-raoar-contact. 

OERRESS  RAOAR-vOOE. 


Figure  3.  Operator  procedures  for  the  radar  plotting  simulation. 
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number  to  use  out  of  the  air.  HOS  would  also  permit  you  to  do  this,  but 
it  can  instead  estimate  for  you  the  amount  of  time  that  it  actually  takas 
to  do  the  radar  plotting,  based  on  the  number  of  contacts  on  the  screen  and 
the  characteristics  of  the  controls,  both  of  which  could  vary  considerably 
during  a  mission  or  from  crewstation  to  crewstation.  To  do  this,  HOS 
requires  an  answer  to  the  question:  How  does  one  do  a  radar  plot? 

The  answer  is  in  our  outline  of  the  operator's  procedures  —  the 
operator  must  first  enable  the  radar  matrix.  How  is  this  done?  By  depres¬ 
sing  RAQAR-MOOE.  He  must  then  search  for  any  radar-contact -symbol  that  is 
-  not  entered  and,  if  he  finds  one,  enter  it  by  moving  the  hook  to  the  radar- 
contact's  position,  depressing  HOOK-VERIFY,  and  depressing  ENTER-RADAR- 
CONTACT.  He  must  then  serach  for  another  radar  contact  thait  has  not  been 
entered  and  enter  it  in  the  same  way.  If  there  are  no  more  to  be  entered, 
he's  done. 


l.B. 4  The  HOS  Radar  Plotting  Simulation 

Once  these  operator  procedures  have  been  combined  with  additional 
procedures  that  describe  how  the  equipment  functions,  with  information  on 
the  actual  crewstation  layout,  and  with  specific  target  data,  HOS  can  simulate 
the  operator's  functions  within  the  crewstation.  The  data  that  HOS  generates 
on  the  operator’s  performance  can  then  be  run  through  an  analysis  program, 

HOOAC,  that  can  produce  eight  different  types  of  analyses  and  an  almost 
infinite  number  of  variants  on  these  analyses  according  to  the  interests 
of  the  analyst.  Examples  of  these  analyses  are  shown  in  Figures  4  through  12  , 
to  indicate  the  wealth  of  information  available  from  HOS. 

Figure  4  is  an  example  of  a  Timeline  Analysis.  It  documents 
what  procedure  the  operator  is  working  on  at  any  Instant  and  what  each  body 
part  is  doing.  The  granularity  of  the  Timeline  Analysis  can  be  chosen  by  the 
analyst  —  in  this  case,  one  second  snapshots  have  been  used.  A  related 
analysis  is  the  Channel  Loading  Report  (Figure  5  )  which  indicates  the 
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percentage  of  time  within  each  snapshot  interval  that  each  body  part  is 
occupied.  The  Devices  by  Body  Part  Analysis  (Figure  6  )  tabulates  the  total 
amount  of  time  each  device  was  used  by  each  body  part  and  calculates  the 
means  and  standard  deviations  for  each  of  three  basic  functions  —  moving 
the  device,  reading  information  from  the  device,  and  performing  a  control 
manipulation  on  the  device.  The  Devices  by  Usage  Analysis  (Figure  7  ) 
provides  summary  data  on  some  of  the  other  types  of  functions  the  operator 
may  be  performing  on  each  device.  The  Devices  by  Procedure  Analysis 
(Figure  8  )  provides  usage  data  statistics  by  procedure.  The  Procedural 
Analysis  (Figure  9  )  summarizes  this  data  over  procedures.  The  Label 
Analysis  (Figure  10)  provides  sumnary  data  for  procedures  and  certain  types 
of  within-procedure  statistics.  And,  finally,  the  Link  Analysis  (Figures  11 
through  12)  provides  data  on  the  frequencies  of  usage  of  groups  of  displays 
and  controls  and  transistions  from  one  group  to  another. 

Section  4  will  describe  in  more  detail  how  each  of  these  reports 
is  to  be  interpreted  and  used. 
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-lOOAC  DEVICE  ANAL  VS  I  S  dV  USAGE 


Figure  7.  HODAC  device#  by  usage  analysis. 
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INFORMATION  ABSORPTION 


•  modalities  are  eyes,  hands,  and 

FEET 


•  HEARING,  SPEECH,  AND  KINESTHETIC 
CUES  ARE  Ufll  MODELED 


•  MODALITIES  ARE  ASSOCIATED  WITH 
DEVICES 


•  OCCURS  AS  A  SERIES  OF  MICRO- 
ABSORPTIONS  THAT  INCREASE  CON¬ 
FIDENCE  (HAB  STRENGTH! 


2.  THE  HOS  OPERATOR  MODELS 

2.1  INFORMATION  ABSORPTION 

2.1.1  Absorption  Modalities 

The  HOS  operator  has  three  modal i ties  by  which  he  can  obtain 
information  —  his  eyes,  hands,  and  feet.  Currently,  neither  hearing  nor 
Speech  nor  any  kinesthetic  cues,  such  as  vibration,  balance,  or  the  per¬ 
ception  of  external  motions  are  simulated.  This  is  not  to  say  that  these 
types  of  cues  don't  exist  —  rather,  we  did  not  feel  that  there  are  currently 
any  satisfactory  models  for  the  effects  that  these  factors  have  on  an 
operator's  performance  that  operated  on  a  level  such  that  we  could  include 
them  in  HOS. 

When  describing  the  displays  and  controls  in  the  operator's  crew- 
station,  the  analyst  must  identify  the  modality  (eyes,  hands,  or  feet)  that 
the  operator  is  to  use  when  obtaining  Information  from  each  device.  Thus, 
if  the  analyst  were  describing  the  displays  and  controls  in  an  automobile, 
he  would  indicate  to  HOS  that  the  operator  is  to  use  his  eyes  to  read  the 
fuel  gauge,  his  hands  to  "read"  the  steering  wheel,  and  his  foot  to  "read" 
the  accelerator. 

The  process  by  which  the  operator  obtains  information  is  the 
same  for  each  modality  and  consists  of  a  series  of  mioro-absorptions .  Each 
micro-absorption  requires  time.  As  the  operator  spends  more  time  (more 
micro-absorptions)  reading  a  device,  both  his  knowledge  of  the  device's 
value  and  his  confidence  in  that  knowledge  increase  until  his  confidence 
exceeds  a  threshold,  at  which  time  the  absorption  process  is  terminated.* 


♦Several  other  conditions  may  cause  an  absorption  to  be  terminated,  as 
will  be  discussed  below. 
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2.1.2  Absorption  Hab  Strengths 

The  quantity  that  represents  the  operator's  confidence  in  his 
knowledge  of  the  value  of  a  device  is  termed  hab  strength,  after  the  learning 
theory  concept  called  "habit  strength"  by  Clark  Hull.  Each  device  has  an 
associated  hab  strength  that  builds  up  during  absorption.  As  the  operator 
spends  more  time  absorbing  information,  the  hab  strength  associated  with 
that  information  increases  until  it  exceeds  a  threshold  value,  at  which  point 
absorption  is  terminated. 

As  an  example,  assume  that  the  operator  is  attempting  to  read  a 
device  (e.g.,  a  warning  light)  that  has  two  discrete  settings  —  on  and 
off.  Successive  micro-absorptions  will  cause  the  hab  strength  to  Increase 
as  shown  in  the  top  curve  in  F1gurel3~  so  that  in  3-4  micro-absorptions, 
the  operator  has,  for  all  intents  and  purposes,  established  in  his  own 
mind  whether  the  display  is  on  or  off.  Using  a  basic  micro-absorption 
time  charge  of  .04,  such  a  read  operation  would  require  .12-. 16  seconds 
(as  compared  to  an  average  rate  for  reading  words  of  approximately  .18 
seconds  per  word).  For  a  display  that  is  more  difficult  to  read,  more 
micro-absorptions  are  required  to  reach  a  comparable  hab  strength,  as  in 
the  second  curve  for  which  the  micro-absorption  time  charge  was  .12. 
Similarly,  displays  that  have  more  potential  values  —  i.e.,  displays  with 
more  settings  or  continuous  displays  —  require  still  more  micro-absorptions 
in  order  to  reach  a  comparable  hab  strength.  The  bottom  two  curves  shown 
in  Figure  13,  for  example,  represent  the  Increase  in  hab  strength  for  two 
continuous  displays  with  micro-absorption  time  charges  equal  to  those  of 
the  two  displays  in  the  upper  curves.  It  should  be  noted  that  the  equations 
used  for  continuous  displays  are  the  same  as  those  for  discrete  displays 
with  seven  or  more  settings  —  i.e.,  discrete  displays  with  more  than  seven 
settings  are  treated  as  if  they  were  continuous. 

Figure  14 shows  the  effect  that  the  micro-absorption  time  charge  can 
have  on  the  amount  of  time  spent  in  a  single, complete  (macro-)  absorption. 

The  four  curves  represent  the  same  four  displays  as  in  the  preceding  figure. 
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In  Figure  14,  however,  it  can  be  seen  that  if  the  operator  spends  as  much 
as  .4  seconds  in  the  absorption  process,  the  hab  strength  for  the  "easy- 
to-read"  continuous  display  will  exceed  the  hab  strength  for  the  difficult 
discrete  display. 

The  primary  criterion  for  terminating  an  absorption  process  is 
for  the  hab  strength  of  the  device  value  being  absorbed  to  exceed  a  threshold 
value,  but  there  are  several  other  conditions  that  the  analyst  can  impose 
as  input  parameters  that  will  terminate  absorption.  These  conditions  are: 

e  A  maximum  amount  of  time  to  be  spent  absorbing. 

e  A  maximum  number  of  micro-absorptions. 

e  A  tolerance  value  that  specifies  that  the  hab  strength  has 
reached  an  asymptote. 

e  A  tolerance  on  the  accuracy  to  which  the  operator  is  required 
to  read  any  device  —  after  which  he  is  considered  to  ',lcnow,, 
the  value  of  the  device. 

The  interaction  between  these  termination  conditions  are  discussed  in  more 
detail  in  the  Appendix. 

2.1.3  Absorption  Estimates  and  Errors 

During  the  absorption  process,  the  operator  acquires  knowledge 
about  the  value  of  a  device  and  confidence  in  his  knowledge  of  that  value. 

The  value  that  the  operator  believes  a  continuous  device  to  have  (the 
iatimatad  value  of  the  device)  Is  determined  from  the  actvol  value  of  the 
device  by  adding  an  error  term  that  is  normally  distributed  about  the  actual 
value  and  whose  magnitude  is  dependent  upon  an  accuracy  for  the  device  as 
supplied  by  the  analyst.  Thus,  if  the  analyst  has  specified  that  a  par¬ 
ticular  device  can  be  read  to  an  accuracy  of  two  percent,  then  two  percent 
of  the  actual  value  of  the  device  is  used  as  the  standard  deviation  when 
computing  the  value  that  the  operator  believes  the  device  to  have  on  any 
specific  absorption. 
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ABSORPTION  ESTIMATES 

NORMALLY  DISTRIBUTED  ABOUT 
THE  ACTUAL  VALUE  OF  THE  DEVICE 

STANDARD  DEVIATION  IS  SUPPLIED 
BY  ANALYST  AS  A  PERCENT 

E.G,,  A  DISPLAY  CAN  BE  READ  +  21 
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INFORMATION  RECALL 


LONG  TERM  RECALL  OF 

~  DEVICE  LOCATIONS 
—  DEVICE  CHARACTERISTICS 
—  PROCEDURES 

—  MENTAL  CALCULATION  PROCESSES 


SHORT  TERM  RECALL  OF 

—  CURRENT  DEVICE  VALUES 


SHORT  TERM  MEMORY 

•  LINKED  TO  PERCEPTION  VIA  HAB 
STRENGTH 

•  PROBABILITY  OF  RECALL  -  H  ^ 

•  REGION  OF  "NEAR-RECALL" 

•  EFFECT  OF  REHEARSAL 
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2.1.4 


Accessing  the  Information  Absorption  Micro-Model 
The  analyst  can  force  the  HOS  operator  to  read  the  value  of  a 
device  by  means  of  the  statement: 

READ  device 

In  addition,  HOS  will  automatically  cause  the  operator  to  read  the  device 
whenever  the  operator  needs  its  value  and  can't  remember  it,  even  if  there 
is  no  explicit  READ  statement. 

2.2  INFORMATION  RECALL 

2.2.1  Long-Term  and  Short-Term  Memory 

The  HOS  information  recall  model  consists  of  two  submodels  --  a 
model  for  short-term  memory  and  one  for  long-term  memory.  The  long-term 
memory  model  is  currently  limited  to  the  recall  of  certain  types  of  pre¬ 
determined  information.  Specifically,  the  HOS  operator  is  assumed  to  have 
a  completely  accurate  and  instantaneous  recall  of  the  locations  of  all  the 
displays  and  controls  in  his  crewstation,  most  of  their  characteristics ,  the 
procedures  that  must  be  followed  in  carrying  out  a  job,  and  the  calculation 
processes  for  any  mental  computations  that  must  be  performed.  These  assump¬ 
tions  are  consonant  with  the  basic  assumption  of  the  HOS  model  —  namely, 
that  the  operator  being  simulated  is  a  trained  operator  who  performs 
routine  operations  automatically. 

The  short-term  memory  model  is  more  elaborate.  Short-term  memory 
is  considered  to  be  linked  to  perception  through  the  hab  strength  concept. 

As  explained  above,  during  the  process  of  absorbing  information,  the  operator’s 
confidence  in  his  knowledge  of  the  value  of  a  device  increases  until  it 
exceeds  a  threshold  at  which  point  the  absorption  process  is  terminated.  The 
ultimate  hab  strength  associated  with  the  device,  a  value  between  zero  and 
one,  constitutes  a  measure  of  the  operator's  confidence  in  his  knowledge 
of  the  device  value. 
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Experimental  data  on  short  term  memory  compared  with 
HOS  Hab  strength  recall  probabilities. 


During  recall,  the  hab  strength  is  used  to  determine  the  prob¬ 
ability  that  the  operator  will  recall  information  absorbed  from  a  device. 
The  probability  of  successful  recall  is  given  by: 


where  H  is  the  hab  strength  and  t  is  the  time  in  seconds  since  the  last 
absorption.  Since  H  is  a  value  between  zero  and  one,  the  probability  of 
recall  is  one  at  time  zero  --  i.e.,  the  operator  has  an  instantaneous  memory 
of  the  value  of  a  device  that  is  perfect,  to  the  extent  that  he  learns  the 
information  in  the  first  place.  Or.e  second  after  .the  completion  of  an 
absorption,  the  probability  of  recall  is  exactly  equal  to  the  hab  strength. 

As  soon  as  absorption  is  complete,  the  probability  of  recall  begins  to 
decay  exponentially  as  shown  in  Figure  15.  Thus,  within  60  seconds  after 
an  absorption  that  had  raised  the  hab  strength  to  .7,  the  probability  of 
successful  recall  would  be  less  than  .1.  If,  however,  the  hab  strength 
had  been  raised  to  .9,  the  probability  of  recall  would  stay  above  the 
level  .1  for  approximately  seven  minutes.  Figure  15  shows  recall  probabilities 
from  some  of  the  available  experimental  data  on  short-term  memory  and  how 
these  data  correspond  to  various  hab  strength  values.  Based  on  these  data, 
we  have  chosen  .8  as  the  default  value  for  the  hab  strength  threshold  — 
the  value  that  is  used  to  determine  when  the  absorption  process  is  terminated. 

The  value  of  P  from  the  probability  of  recall  equation: 


is  compared  against  a  number  drawn  at  random  from  a  uniform  distribution. 

If  the  randomly  drawn  number  is  less  than  P,  then  the  information  is 
"remembered."  If  the  randomly  drawn  number  is  much  larger  than  P,  then  the 
information  is  "forgotten."  If,  however,  the  randomly  drawn  number  is 
close  to  P,  then  the  model  assumes  that  the  operator  is  in  a  region  of 
"near-recall,"  where  given  a  little  more  time,  he  might  remember.  A  second 
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time  since  last  absorption  seci 

Figure  17.  Recall  increments  for  continuous  devices. 
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random  number  is  therefore  drawn  and  compared  with  P  to  determine  whether 
the  information  is  remembered,  forgotten,  or  in  the  near-recall  region. 

Usually  a  second  draw  will  suffice  —  the  random  number  will  either  be  in 
the  remembered  or  forgotten  region.  But  the  process  could  theoretically  go 
on  for  three  or  more  tries.  Each  try  results  in  the  addition  of  a  small 
amount  of  time,  the  short-term  memory  cycle  time,  to  the  total  time  for 
retrieval  from  short-term  memory  (Figure  16). 

When  the  operator  recalls  a  value,  the  hab  strength  associated 
with  that  value  is  changed  in  order  to  simulate  the  effects  of  rehearsal. 

The  remembered  value  is  given  a  hab  strength  that  is  lower  than  if  the 
information  had  been  absorbed  again,  but  higher  than  it  would  have  been  had 
the  normal  decay  curve  been  followed  (Figure  17). 

There  are  several  features  of  this  recall  model  that  deserve 
some  comment  (and  probably  some  future  work).  First,  the  process  by  which 
the  hab  strength  associated  with  any  item  of  information  is  increased  and 
recalled  is  independent  of  the  value  of  information  to  the  operator  —  the 
threshold  value  is  the  same  for  all  information  and  consequently  all  items 
of  information  follow  essentially  the  same  curves  for  the  increase  and 
decrease  in  hab  strength.  This  is  clearly  unrealistic  —  information  that 
is  of  greater  value  to  the  operator  should  decay  less  rapidly  and  should 
be  learned  to  a  higher  level  of  confidence  than  less  important  information. 
Secondly,  the  recall  model  has  no  explicit  provision  for  allowing  information 
to  transfer  from  short-term  memory  to  long-term  memory,  though  there  is 
an  effective  transfer  that  results  from  rehearsal  for  the  real  human  operator. 
Third,  there  is  no  linkage  between  items  of  information  —  if,  for  example, 
the  operator  depresses  a  switch  that  changes  the  value  of  a  display,  that 
action  will  normally  not  affect  the  value  that  the  simulated  operator  will 
recall  for  the  display,  whereas  a  true  operator  would  certainly  know  that 
the  displayed  value  had  changed.*  And  fourth,  there  are  no  external  cues 


*Although  the  analyst  can,  in  fact,  specify  that  such  linkages  exist 
when  coding  the  procedures. 
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AREAS  FOR  IMPROVEMENT  IN  MEMORY  MODEL 

HAB  STRENGTH  IS  INDEPENDENT  OF  THE  VALUE  OF  INFORMATION 

NO  EXPLICIT  PROVISION  FOR  TRANSFER  FROM  SHORT-TERM  TO 
LONG-TERM  MEMORY 

NO  LINKAGE  BETWEEN  ITEMS  OF  INFORMATION 
NO  IMPACT  FROM  EXTERNAL  CUES 
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that  impact  the  perceived  or  recalled  value  of  a  device,  as  the  view  out 
the  window  might  cue  the  recall  of  the  altimeter  value  for  an  aircraft 
pilot. 

2.2.2  Errors  During  Recall 

For  continuous  devices,  there  is  a  portion  of  the  recall  model 
that  simulates  the  decreased  accuracy  associated  with  the  recalled  value. 
The  basic  premise  behind  this  feature  of  the  recall  model  is  that  as  con¬ 
fidence  (i.e.,  hab  strength)  in  the  value  of  a  device  decreases,  the  pre¬ 
cision  of  the  value  that  the  operator  recalls  for  the  device  will  also 
decrease.  Thus,  if  at  some  later  time,  the  operator  is  asked  for  the  value 
of  the  device,  then  the  operator  will  be  able  to  supply  fewer  "significant 
digits"  as  the  time  from  the  last  absorption  of  the  value  of  the  device 
increases.  We  term  this  process  modular  deoay.  The  modular  decay  function 
is  such  that  given  an  initial  device  value  of,  for  example,  123456  and  an 
initial  hab  strength  of  .8,  the  modularly  decayed  values  would  be  as  shown 
in  Figure  18. 

2.2.3  Extrapolation  of  Values 

If  the  operator  can  recall  the  value  that  a  continuous  device 
had  the  last  time  he  read  it,  then  HOS  enables  the  operator  to  extrapolate 
its  value  to  the  current  time.  The  extrapolation  is  linear  and  based  on 
the  two  preceding  absorbed  values  and  the  times  when  those  values  were 
obtained.  It  is  the  responsibility  of  the  HOS  user  to  declare  whether  or 
not  extrapolation  is  to  be  permitted  for  each  device. 

2.2.4  Accessing  the  Information  Recall  Micro-Model 

The  analyst  can  force  the  operator  to  attempt  to  recall  the  value 
of  a  device  by  the  use  of  the  statement: 

RECALL  device 

However,  this  statement  is  rarely  used.  Rather,  the  recall  model  is  almost 
always  accessed  implicitly  by  simply  including  the  device  name  within  the 
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Figure  IB.  Modular  decay  examples. 


context  of  another  statement.  When  HOS  recognizes  that  a  device  value  is 
needed,  it  will  attempt  to  recall  the  value. 

2.4.5  Scope  of  the  Information  Absorption  and  Recall  Models 

The  estimated  value  of  a  device  is  the  only  characteristic  of  a 
device  that  is  either  recalled  or  read  by  the  HOS  operator.  The  operator 
does ,  however,  maintain  other  information  on  other  device  characteristics  — 
desired  values,  upper  limits,  lower  limits,  etc.  —  but  these  quantities 
(termed  device  parameters)  are  considered  to  be  resident  in  the  operator's 
long-term  memory  and  therefore  are  not  subject  to  the  information  absorption/ 
recall  processes.  The  various  device  parameters  are  listed  in  Figure  19- 

2.3  MENTAL  COMPUTATION 

The  mental  calculations  performed  by  the  HOS  operator  are  termed 
operator  functions ,  or  simply  functions. 

The  mental  calculation  micro-model  uses  the  hab  strength  construct 
in  much  thesameway  as  the  information  absorption  and  information  recall 
micro-models.  The  result  of  a  mental  computation  has  an  associated  hab 
strength  that  represents  the  operator’s  confidence  in  the  computed  data. 

As  the  operator  spends  more  time  on  the  computation,  his  confidence  in  his 
estimate  increases  until  either: 

•  The  hab  strength  threshold  is  exceeded. 

•  The  hab  strength  has  asymptoted. 

•  The  maximum  number  of  iterations  through  the  hab  strength 
incrementing  process  has  been  exceeded. 

•  The  amount  of  time  spend  in  computation  exceeds  a  maximum 
allowable  computation  time. 

The  recall  model  for  mentally  computed  data  is  identical  to  the  model  used 
for  any  other  type  of  data. 
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DEVICE  PARAMETERS 

•  desired  value 

•  RATE  OF  CHANGE 

•  TIME  (OF  LAST  ESTIMATE) 

•  X  AND  Y  COMPONENTS 

«  UPPER  AND  LOWER  LIMITS 

•  criticality 

•  STATE  (ACTIVE  OR  INACTIVE) 

•  estimated  value 


Figure  19.  Device  parameters. 
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The  basic  difference  between  the  mental  computation  model  and 
the  information  absorption  model  is  that,  in  the  latter,  information  is 
absorbed  from  a  display  or  control  in  the  crewstatlon,  whereas  in  the  former, 
displayed  information  is  used  to  determine  a  value  that  is  not  displayed 
anywhere  in  the  crewstation.  For  example,  a  typical  mental  computation 
when  driving  an  automobile  is  determining  how  much  farther  one  can  go  on 
a  tank  of  gas.  The  computation  requires  the  absorption  of  an  item  of 
information  (the  amount  of  fuel  remaining)  coupled  with  some  prior  knowledge 
(the  number  of  miles  per  gallon). 

When  a  mental  calculation  is  required,  HOS  will  determine  what 
information  is  needed  in  order  to  perform  the  calculation.  If  the  HOS 
operator  can  remember  the  information,  the  calculation  is  performed  at 
once.  If  he  cannot  remember  the  information,  an  appropriate  sequence  of 
actions  is  initiated  to  enable  the  operator  to  obtain  the  data.  In  the  above 
example,  the  displayed  information  required  is  the  amount  of  fuel  remaining. 
If  the  operator  cannot  remember  this,  HOS  would  cause  him  to  look  at  the 
fuel  gauge  and  read  its  value. 

Each  mental  calculation  can  require  as  many  as  ten  different  data 
items.  These  may  be  the  values  of  displays  or  controls  or  the  results  of 
other  mental  calculations.  An  unlimited  number  of  parametric  values  are 
also  allowed.  The  amount  of  time  required  for  a  mental  calculation  is 
considered  to  be  the  amount  of  time  required  to  gather  all  the  items  of 
information  needed  for  the  calculation  plus  some  additional  time  to  "put 
it  all  together."  Because  of  the  high  potential  variability  in  a  function 
calculation,  the  analyst  is  required  to  supply  a  function  computation  time 
for  each  function  —  HOS  itself  will  supply  the  times  required  to  gather 
all  the  items  of  information  needed  for  the  calculation. 

A  second  difference  between  the  mental  computation  and  information 
absorption  models  is  that  in  the  information  absorption  model,  the  minimum 
hab  strength  associated  with  a  device  is  dependent  on  the  number  of  settings 


53 


MENTAL  COMPUTATION 

USES  HAB  STRENGTH  CONSTRUCT 

COMPUTATIONS  REQUIRE  INFORMATION 
FROM  OTHER  DEVICES 

ANALYST  SUPPLIES  A  COMPUTATION  TIME 

HAB  STRENGTH  IS  DEPENDENT  ON  HAB 
STRENGTHS  OF  COMPONENT  DATA 

CALCUALTIONS  ARE  ERROR-FREE;  DATA  INPUT 
TO  CALCULATIONS  ARE  NOT 
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associated  with  the  device.  In  the  case  of  mental  computations,  the  hab 
strength  associated  with  the  operator  function  is  the  minimum  hab  strength 
associated  with  any  of  the  components  in  the  function  calculation. 

Errors  in  mental  computation  are  assumed  to  be  the  result  of 
errors  associated  with  the  data  that  goes  into  the  calculation  itself.  The 
calculation  process  itself  is  considered  to  be  error-free.  Thus,  if  the 
operator  makes  an  error  or  obtains  an  inaccurate  data  value  when  either  recal¬ 
ling  the  data  or  reading  the  data  needed  for  a  calculation,  then  the  result  of 
the  calculation  will  be  incorrect,  or  inaccurate,  according  to  the  incorrect¬ 
ness  or  inaccuracy  of  the  incoming  data.  If  the  data  values  are  correct  and 
accurate,  then  the  result  of  the  calculation  will  be  accurate.  It  should  be 
noted,  however,  that,  as  a  result  of  the  way  in  which  mental  calculations 
are  described  to  HOS,  the  analyst  has  the  ability  to  inject  errors  into  the 
function  calculation  if  he  so  chooses. 

2A  MAKING  A  DECISION 

HOS  decision-making  takes  place  at  two  levels  —  the  inter¬ 
procedural  and  the  intra-procedural  levels.  To  understand  what  is  meant 
by  this,  we  have  to  explain  what  is  meant  by  a  procedure,  A  procedure  is 
an  operator  task  consisting  of  any  number  of  steps ,  any  step  of  which  can 
invoke  the  execution  of  another  procedure  or  any  other  operator  action.  For 
example,  the  operator's  mission  in  any  particular  simulation  is  a  procedure 
that  invokes  other  procedures  —  a  pilot's  mission  may  invoke  a  procedure 
for  takeoff,  another  for  cruise,  another  for  landing,  etc.  Within  these 
procedures  (or  any  procedures  that  they  invoke)  there  are  steps  that  describe 
operator  actions  —  reading  a  display,  adjusting  a  control,  etc.  decision- 
making  can  therefore  operate  at  two  different  levels  --  deciding  what  procedure 
to  perform  from  a  set  of  available  active  procedures,  or  deciding  what  to  do 
next  within  any  particular  procedure. 
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HOS  gives  the  analyst  the  option  of  both  limited  and  total  control 
over  these  decisions.  The  analyst  can  opt  for  total  control  in  the  sense 
that  simulations  can  be  constructed  that  force  the  operator  to  follow  a 
specific  sequence  of  steps  and  procedures.  The  analyst  can,  instead,  choose 
limited  control  in  the  sense  that  the  exact  sequence  of  task  and  subtask 
operations  that  an  operator  will  use  is  unknown  —  the  simulation  can  be 
constructed  so  that  the  HOS  operator  is  allowed  to  make  decisions  for  him¬ 
self  in  accordance  with  a  flexible  task  structure.  Such  a  flexible  structure 
is  appropriate  because,  like  a  real  operator,  HOS  can  adapt  its  actions  to 
situations.  The  power  of  HOS  lies  in  its  ability  to  adapt  its  performance 
to  situations  in  a  natural  and  realistic  fashion. 

Decisions  about  what  to  do  next  'jithin  a  procedure  are  fairly 
simple.  HOS  will  attempt  to  execute  each  step  in  a  procedure  in  sequence 
until  it  can  go  no  further,  for  whatever  reason.  If  it  finds  itself  blocked, 
it  will  attempt  to  "unblock"  iteslf.  If  it  can,  it  will  continue  marching 
forward;  if  it  can't,  it  will  look  for  some  other  procedure  to  work  on,  at 
which  point  the  decision-making  logic  for  selecting  a  procedure  is  invoked. 

As  it  marches  forward  in  a  procedure,  HOS  may  encounter  a  state¬ 
ment  that  requires  a  decision,  l.e.,  an  IF  statement.  The  IF  statement 
requires  the  operator  to  make  a  decision  about  the  current  status  of  informa¬ 
tion  or  events  in  the  simulation.  If  the  condition(s)  tested  is  (are) 
satisfied,  then  it  proscribes  a  set  of  actions  to  be  taken.  If  the  condition(s) 
is  (are)  not  satisfied,  the  actions  are  not  performed.  A  small  time  charge 
is  assessed  for  this  decision-making  function  over  and  above  the  time 
charges  associated  with  gathering  the  information  needed  for  the  decision. 

There  are  basically  three  types  of  events  that  will  block  the 

operator: 

(1)  An  action  is  required  that  the  operator  cannot  perform 
because  the  action  requires  body  resources  that  are  busy 
doing  something  else. 
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DECISION  MAKING  (WITHIN  A  PROCEDURE) 


OPERATOR  EXECUTES  STEPS  SEQUENTIALLY  UNTIL  "BLOCKED" 

•  BODY  PART  UNAVAILABLE 

•  CONTROL  DEVICE  UNAVAILABLE 

•  INFORMATION  UNAVAILABLE 

A  STEP  MAY  REQUIRE  A  DECISION 

ANOTHER  PROCEDURE  CAN  BE  INVOKED  TO  BE  EXECUTED 

•  IMMEDIATELY 

•  AS  TIME  PERMITS 

•  PERIODICALLY 
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DECISION  MAKING  (BETWEEN  PROCEDURES) 


SELECTION  OF  A  PROCEDURE  IS  DEPENDENT 
ON: 

•  CRITICALITY  (PRIORITY)  OF  THE 
PROCEDURE 

•  HOW  LONG  IT  HAS  BEEN  SINCE  THE 
PROCEDURE  WAS  LAST  EXECUTED 


INITIAL  CRITICALITIES  SET  BY  ANALYST 
AND  CAN  BE  CHANGED  DYNAMICALLY 


EFFECTIVE  CRITICALITY  FOR  MONITOR  PRO¬ 
CEDURES  IS  DEPENDENT  ON  HOW  CLOSE  A 
DEVICE  IS  TO  ITS  DEFINED  LIMITS 
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(2)  The  operator  requires  information  that  is  currently  unavail¬ 
able  because  a  device  in  inactive  (not  enabled),  or 

(3)  The  operator  must  perform  a  control  action  that  cannot  be 
performed  because  the  control  is  inactive  (not  enabled). 

Of  these  situations,  the  latter  two  are  the  more  common.  When 
they  occur,  HOS  will  automatically  invoke  a  special  type  of  procedure  — 
an  enable  procedure  —  whose  function  is  to  activate  the  device  that  is 
inactive.  When  the  first  situation  occurs,  HOS  will  simply  go  off  and  work 
on  another  procedure  until  the  required  body  part  is  free. 

One  of  the  actions  that  can  be  performed  within  a  procedure  is  the 
invocation  of  another  procedure.  When  a  procedure  is  invoked,  the  analyst 
can  specify  either  that: 

(1)  The  procedure  is  to  be  executed  immediately  and  no  more 
steps  in  the  current  procedure  are  to  be  executed  until 
the  invoked  procedure  has  been  completed,  or 

(2)  The  invoked  procedure  is  to  be  placed  on  an  active  procedure 
list  and  is  to  be  executed  as  soon  as  appropriate,  or 

(3)  The  invoked  procedure  is  to  be  executed  periodically  until 
removed  from  the  active  procedure  list. 

In  situation  (1),  control  transfers  immediately  to  the  invoked 
procedure  and  no  more  steps  in  the  invoking  procedure  are  executed  until  the 
invoked  procedure  is  completed.  The  active  procedure  list,  formed  by  invok¬ 
ing  procedures  by  methods  (2)  and  (3),  is  the  list  of  procedures  available 
to  the  operator  when  he  finds  himself  blocked  in  his  current  procedure.  Pro¬ 
cedures  placed  on  the  active  procedure  list  by  method  (3)  are  called  monitor 
procedures  in  that  they  are  usually  used  to  cause  the  operator  to  periodically 
monitor  a  particular  display  or  control. 

Finally,  the  analyst  can  force  a  procedure  to  be  selected  from  the 
active  procedure  by  using  special  forms  of  the  IF  and  GO  TO  statements  (see 
below) . 


TIME  SINCE  LAST  EXECUTED 


Figure  20.  Increase  in  procedural  criticality  with  time. 


ESTIMATED  VALUE  »  2*  UPPER  LIMIT 


ESTIVATED  VALUE 


UPPER  LIMIT 


ESTIMATED  VALUE  ■  DESIRED  VALUE  •  0 


TIME  since  last  executed 

Figure  21.  Increase  in  criticality  for  monitor  procedures. 


When  a  procedure  is  to  be  selected  from  the  active  procedure  list, 
there  is  a  model  that  represents  the  operator's  procedural  selection  process. 
This  model  considers  two  factors: 

(1)  The  criticality  (priority)  of  the  procedure,  and 

(2)  How  long  it  has  been  since  the  procedure  was  last  executed. 

A  detailed  discussion  of  the  interaction  of  these  factors  is 
presented  in  Appendix  A  of  this  document.  Briefly,  as  the  length 
of  time  since  the  procedure  was  last  executed  increases,  the  effective 
criticality  of  the  procedure  increases  (over  an  initial  criticality  that 
can  be  set  by  the  analyst),  as  shown  in  Figure  20.  In  addition,  for 
monitor  procedures,  the  effective  criticality  is  further  modified  by  a 
factor  that  is  dependent  on  how  close  the  device  being  monitored  is  to  a 
defined  set  of  limits.  As  the  estimated  value  of  the  device  approaches  its 
limits,  the  effective  criticality  of  the  device  increases.  When  it  exceeds 
the  defined  limits,  the  effective  criticality  increases  very  rapidly,  as 
shown  in  Figure  21.  The  computed  effective  criticalities  for  each  procedure 
on  the  active  procedure  list  are  compared  and  the  procedure  with  the  highest 
effective  criticality  is  chosen  as  the  next  procedure  to  work  on. 

2.5  ANATOMY  MOVEMENT 

The  anatomy  movement  micro-model  is  almost  always  accessed  Implicitly 
i.e.,  the  analyst  will  rarely  issue  a  command  that  will  force  a  body  movement. 
Rather,  HOS  itself  will  determine  whether  a  body  movement  is  required  in 
order  to  accomplish  the  objective  of  an  instruction.  If  it  decides  that  a 
body  movement  is  required,  HOS  will  automatically  select  the  appropriate 
body  part,  move  it  to  the  required  location,  and  add  to  the  simulation  time 
a  computed  estimate  of  the  amount  of  time  the  action  would  have  taken  a 
real  operator.  For  example,  suppose  a  procedural  statement  says: 

TURN  SWITCH-A  ON. 
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BODY  PART  SELECTION 


•  EYES 

•  HANDS 

—  RIGHT  OR  LEFT? 
—  IS  HAND  BUSY? 
—  SWAP  HANDS? 

•  FEET 

—  RIGHT  OR  LEFT? 
—  IS  FOOT  BUSY? 
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If  HOS  decides  that  this  action  is  necessary,*  and  if  one  of  the  operator's 
hands  is  not  already  on  SWITCH-A,**  HOS  will  select  a  hand,  "move"  it  to 
SWITCH-A,  and  charge  an  amount  of  time  equal  to  the  time  that  a  real  operator 
would  have  taken  to  move  that  hand  to  SWITCH-A  from  wherever  the  hand  was 
at  the  time  the  instruction  was  issued. 

Thus,  the  moving  and  grasping  primitive  function  consists  of  two 
micro-models  --  one  to  determine  which  body  part  to  use  for  a  particular 
action,  the  other  to  assign  a  time  charge  for  the  movement.  The  body  part 
selection  micro-model  is  based  on  several  common-sense  principles.  The 
first  is  that  the  body  part  to  be  used  is  determined  by  the  function  to  be 
performed  and  the  device  being  referenced.  Thus,  if  the  operator  is  going 
to  be  reading  data  from  a  device,  the  eyes  are  usually  the  appropriate  body 
part  to  use.  However,  there  may  be  some  devices  whose  value  cannot  be 
determined  visually  —  touching  them  with  a  hand  or  foot  may  be  more  appro¬ 
priate.  Some  devices  may  use  two  modalities  —  the  eyes  are  used  to  absorb 
information  while  the  hands  are  used  when  the  device  is  to  be  altered.  HOS 
permits  the  analyst  to  specify  for  each  device  the  most  appropriate  modality 
for  each  function  (reading  and/or  altering). 

If  the  operator's  eyes  are  to  be  used  for  a  specific  function, 
there  is  no  problem  —  the  HOS  operator  has  only  one  pair  of  eyes  which  are 
immediately  moved  to  the  device.  The  time  charge  assigned  for  an  eye  move¬ 
ment  is  computed  from  an  equation  that  was  developed  by  fitting  the  data 
from  an  experiment  that  involved  lateral  eye  movements  (Dodge  and  Cline, 

1901)  and  from  an  unpublished  experiment  by  Wherry  and  Bittner  that  involved 
both  lateral  and  convergence  movements. 


*SWITCH-A  may  be  ON.  A  real  operator,  if  he  remembered  this,  would  not 
perform  the  action.  Similary,  HOS  would  decide  whether  the  simulated  operator 
remembered  whether  the  device  was  on  and,  if  he  did,  would  not  initiate  the 
body  movement. 

♦•Assuming  that  SWITCH-A  is  a  device  that  is  turned  on  by  hand. 
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ANATOMY  MOVEMENT  (MOVING  AND  GRASPING) 

•  EXPLICIT  ACCESS: 

LOOK  AT  THE  ALTIMETER 

•  IMPLICIT  ACCESS: 

TURN  SWITCH-A  ON 

•  SELECT  APPROPRIATE  BODY  PART 

•  MOVE  IT  TO  REQUIRED  LOCATION  AND  ADD 
TIME 
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The  equation: 

T  3  .14324  A  +  .0175 


where 

A  =  max  (A9,  A<j>)  +  .2  min  (A0,  A4>) 

and 

P  P 

M  ’  I  tan“  !OT5;i  •  ta"‘‘  <07?)  1 

49  ‘  1  cos"  ‘TT'TTFfl1  1 

P-j  3  vector  from  design  eye  point  to  fixation  point  1 

~  vector  from  design  eye  point  to  fixation  point  2 

assumes  that  both  the  lateral  and  convergence  movements  can  proceed  in 

parallel  at  the  same  rate  with  the  total  movement  time  being  dependent  on 
which  movement  takes  the  greater  amount  of  time. 


When  one  of  the  operator's  hands  is  needed,  the  problem  is  not 
quite  so  simple  —  it  is  necessary  for  HOS  to  decide  which  hand  to  use. 

The  logic  that  HOS  uses  is  fairly  complex:  (Figure  22.) 

(1)  HOS  will  attempt  to  use  the  hand  that  is  currently  closer 
to  the  device,  unless  that  hand  is  currently  busy  doing 
something  else. 

(2)  If  the  preferred  hand  is  busy,  but  will  be  free  "soon," 
where  "soon"  is  an  amount  of  time  that  can  be  set  by  the 
analyst,  then  HOS  will  "wait"  until  the  preferred  hand  is 
free  and  will  then  "move"  the  operator's  hand  to  the 
device. 

(3)  If  the  preferred  hand  will  not  be  free  soon,  then  the 
operator's  other  hand  is  used  —  assuming  that  it  is  free  and 
can  reach  the  device. 

(4)  If  the  operator's  other  hand  is  not  free,  but  will  be  soon, 
HOS  will  again  wait  until  that  hand  is  free  and  then  use  it. 
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•  WHICH  BODY  PART  IS  APPROPRATE  TO  THE  TASK 

•  WHICH  BODY  PART  IS  CLOSER 

•  IF  THE  PREFFERED  BODY  PART  IS  "BUSY."  WILL 

IT  BE  FREE  WITHIN  A  REASONABLE  AMOUNT  OF  TIME 

•  IF  IT  WON'T  BE  FREE,  CAN  THE  FUNCTIONS  WHICH 
IT  IS  PERFORMING  BE  PERFORMED  BY  ANOTHER  BODY 
PART 


Figure  22.  Anatomy  Movement  Logic 
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(5)  If,  however,  the  operator's  other  hand  cannot  reach  the 
device,  then  a  determination  is  made  as  to  whether  a  hand 
3wap  should  be  initiated.  In  a  hand  swap,  the  less  pre¬ 
ferred  hand  takes  over  the  function  being  performed  by  the 
preferred  hand  so  that  the  operator  can  move  the  preferred 
hand  to  the  device. 

(6)  If  both  hands  are  busy  and  won't  be  free  for  some  time,  or 
if  a  hand  swap  cannot  be  performed,  HOS  will  decide  that  the 
instruction  is  unexecutable  and  will  delay  the  execution  of 
the  procedure  in  which  that  statement  is  found  until  one 

of  the  operator's  hands  is  free. 


Similar  logic  pertains  to  the  use  of  the  operator's  feet  with  the 
exception  that  "swaps"  cannot  take  place. 

The  time  required  for  a  hand  or  foot  movement  is  assumed  to  depend 
on  both  the  magnitude  and  the  precision  of  the  movement.  The  equations  that 
determine  how  long  a  hand  movement  will  take  are  a  combination  of  the  results 
of  experiments  by  Fitts  and  by  Topmiller  and  Sharp  and  are  discussed  in 
detail  in  Appendix  A  of  this  document.  These  data  are  shown  in 
Figure23  where  they  are  compared  with  other  hand  movement  studies.  The  same 
equations  are  also  currently  being  used  for  foot  movements,  but  with  different 
basic  parameter  values. 


Some  key  characteristics  of  the  anatomy  movement  micro-model  that 
should  be  noted  here  are: 

(1)  Movements,  like  the  instructions  that  initiate  them,  are 
executed  serially  for  each  body  part. 

(2)  Movements  are  ballistic  —  once  initiated  they  cannot  be 
stopped  nor  can  another  action  be  initiated  while  the 
movement  is  taking  place. 

(3)  Movement  times  are  fully  deterministic,  based  on  where  a 
body  part  is  and  where  it  is  being  moved  to  --  there  is 
no  variability. 

(4)  If  a  movement  cannot  be  performed,  an  interrupt  will  be 
generated  enabling  the  operator  to  select  another  procedure 
from  the  active  procedure  list  for  execution. 
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DISTANCE  IN  INCHES 


anatomy  movement  micro-model  features 

•  ACTIONS  ARE  INITIATED  SERIALLY  FOR  EACH  BODY 
PART 

•  ACTIONS  ARE  BALLISTIC 

•  EACH  BODY  PART  HAS  A  RELAXED  LOCATION 

•  BODY  PARTS  RETURN  TO  RELAXED  LOCATION  AFTER  A 
SPECIFIED  TIME 

•  RETURN  TO  THE  RELAXED  LOCATION  CAN  BE  OVERRIDEN 
BY  SPECIFYING  A  GRASP  LOCATION 

•  UNEXECUTABLE  ACTIONS  CAUSE  SUSPENSION  OF  PROCEDURE 


CONTROL  MANIPULATION 


DISCRETE  CONTROLS 

—  TIME  TO  MANIPULATE  IS  A  FUNCTION 
OF  THE  NUMBER  OF  SETTINGS  THAT  WILL 
BE  PASSED  THROUGH 


CONTINUOUS  (ROTARY)  CONTROLS 

—  TIME  IS  DEPENDENT  ON  FORCE  REQUIRED 
AND  ANGULAR  CHANGE 


CONTROL  MANIPULATIONS  CAN  BE  PERFORMED  IN 
PARALLEL 
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2.6  PERFORMING  A  CONTROL  MANIPULATION 

Times  associated  with  control  manipulations  are  highly  variable 
because  of  the  diverse  types  of  controls  used  in  different  operator  stations. 
Consequently,  HOS  allows  the  user  to  describe  the  characteristics  of  a  con¬ 
trol  which  are  used  to  determine  a  set  of  equations  that  describe  the  time 
associated  with  a  control  manipulation.  In  addition,  there  are  a  set  of 
"packaged"  calculations  that  compute  control  manipulation  times  for  two 
basic  control  types  —  discrete  controls  and  continuous  rotary  knobs. 

For  discrete  controls,  the  analyst  is  required  to  supply  a  time 
that  represents  the  time  required  to  move  the  control  through  a  single 
setting.  If  a  control  manipulation  results  in  a  movement  through  several 
settings,  the  time  assigned  will  be  the  time  required  for  a  single  setting 
multiplied  by  the  number  of  settings. 

The  formula  for  the  manipulation  time  for  a  continuous  rotary 
control  was  derived  by  fitting  a  quadratic  to  a  table  of  data  presented  by 
Karger  and  Bayha  (1966).  The  resultant  formula  is: 

T  =  .0482  +  . 0Q50F  +  .0084  FA 

where  F  is  the  force  in  pounds  required  to  turn  the  control  and  A  is  the 
angle  through  which  the  control  is  to  be  turned,  in  radians. 

Unlike  some  of  the  other  actions  that  we  have  discussed  —  infor¬ 
mation  absorption,  recall,  anatomy  movement,  etc.  —  once  initiated,  con¬ 
trol  manipulations  can  proceed  in  parallel  with  other  actions.  Thus,  the 
operator  san  be  performing  manipulations  concurrently  with  both  his  right 
and  left  hands.  In  fact,  one  of  the  H0PR0C  lanugage  constructs  (the 
"parallel"  alter)  enables  the  analyst  to  specify  that  two  or  more  actions 
must  be  carried  out  simultaneously. 
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L  DESIRED  LOCATION 

£  ) 

PREFERRED  LOCATION 

t 


RELAXED  LOCATION 


'J 


BODY  PARTS  RETURN  TO  A  RELAXED 
LOCATION  WHEN  NOT  IN  USE. 


A  "grasp"  LOCATION  CAN  BE  ASSIGNED 
THAT  TEMPORARILY  OVERRIDES  THE 
RELAXED  LOCATION 


Figure  2*.  Relaxation  Logic 


2.7  RELAXATION 

The  HOS  relaxation  micro-model  interfaces  with  all  the  other 
action  micro-models.  Though  fatigue  itself  is  not  currently  modeled,  HOS 
does  exhibit  one  related  characteristic  that  a  real  operator  tends  to  exhibit 
when  body  parts  are  not  busy  doing  anything  else,  the  operator  will  move 
them  to  a  comfortable,  relaxed  location.  The  analyst  can  override  this 
default  location  by  specifying  a  grasp  location  —  a  location  at  which 
some  action  is  expected.  But  after  the  operator  has  performed  an  action 
at  the  grasp  location,  the  appropriate  body  part  will  automatically  return 
to  its  relaxed  location. 

This  logic  is  summarized  in  Figure  24.  Any  action  establishes 
a  location  to  which  the  operator  must  move  in  order  to  carry  out  the  action. 
After  the  action  has  been  carried  out  (and  after  a  specified  interval  of 
time  has  elapsed)  the  body  part  will  return  to  the  grasp  location  (if  one 
has  been  established)  or  to  the  relaxed  location,  if  no  other  actions 
require  that  body  part.  After  an  action  occurs  at  the  grasp  location,  that 
location  is  eliminated,  and  body  parts  return  to  the  relaxed  location. 

2.8  OPERATOR  VARIABILITY 

As  described  above,  most  of  the  equations  that  govern  the  operator 
micro-models  in  HOS  are  fully  deterministic.  This  is  consistent  with  two 
of  the  premises  in  the  HOS  model  --  that  the  operator  is  a  trained  operator 
and  that  performance  variations  observed  in  experiments  on  individual 
operators  are  largely  the  result  of  situational  differences,  as  opposed  to 
differences  in  basic  performance  parameters.  However,  there  are  clearly 
differences  in  ooerator  performance  --  both  between  operators  and  for  the 
same  operator-  under  different  operational  conditions.  Some  of  the  HOS 
operator  parameters  mentioned  above  enable  the  analyst  to  examine  the 
effects  of  such  differences  --  the  short-term  memory  cycle  time,  hab  strength 
threshold,  etc.  In  addition,  by  modifying  the  equations  described  above, 
one  can  readily  describe  an  operator  with  a  different  performance  profile. 
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OPERATOR  VARIABILITY 


EXPRESSED  THROUGH  OPERATOR  PARAMETERS 

•  SHORT-TERM  MEMORY  CYCLE  TIME 

•  HAB  STRENGTH  THRESHOLDS 


CAN  BE  EFFECTED  THROUGH  PERFORMANCE 
EQUATIONS 

"OPERATOR  STATES"  CONSTRUCT 
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Finally,  there  is  a  HOS  construct  that  was  a  part  of  the  original  concept 
of  HOS  that  was  intended  to  model  such  performance  differences  under 
differing  internal  and  external  states.  However,  the  operator  states 
(o-states)  concept  has  not  as  yet  been  implemented  because  of  the  challenge 
that  has  so  far  confronted  us  in  modeling  average  performance  when  no 
special  stresses  are  influencing  the  operator. 
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HOPROC 


OBJECTIVE:  A  LANGUAGE  THAT  WAS 

~  flexible 

—  ADAPTABLE 

—  NON-SPECIFIC  TO  A  PARTICULAR  CREWSTATION 

OBJECTIVE  ACHIEVED  WITHIN  THE  CONSTRAINT  THAT  HOPROC 
HAD  TO  BE  ABLE  TO  BE  USED  TO  SIMULATE  A  SPECIFIC  CREW 
STATION. 


EXAMPLES : 

IN  DECLARATIONS  SECTION,  NO  DETAILS  ABOUT  DISPLAY/ 
CONTROL  LOCATIONS  OR  MOST  OPERATIONAL  CHARACTER ISTICS 
ARE  NEEDED. 


FUNCTIONS  AND  PROCEDURES  ARE  MODULAR  AND  CAN  BE 
READILY  MODIFIED  FOR  USE  IN  OTHER  SIMULATIONS. 


HOPROC  IS  FREE-FORMAT,  ENGLI SH/FORTRAN-LI KE,  AND  CAN 
BE  READILY  UNDERSTOOD  BY  THOSE  WITH  LITTLE  FAMILIARITY 
WITH  IT, 


3.  THE  HOPROC  LANGUAGE 


3.1  INTRODUCTION 

The  HOS  mission  description  is  written  in  the  HOPROC  language. 
The  primary  objectives  in  developing  HOPROC  have  been  to  construct  a  lan¬ 
guage  that  would  be  flexible,  adaptable,  easy  to  understand,  and  non¬ 
specific  to  a  particular  crewstation,  and  that  would,  at  the  same  time, 
be  able  to  describe  the  operator's  crewstation  and  tasks  in  sufficient 
detail  that  they  could  be  accurately  simulated.  Attainment  of  these  goals 
was  constrained  by  the  fact  that  a  specific  crewstation  must  be  described 
in  order  for  HOS  to  simulate  the  operator's  performance  within  the  crew¬ 
station.  But,  even  with  this  constraint,  we  feel  that  HOPROC  has  achieved 
its  major  objectives. 


Some  of  the  ways  in  which  these  objectives  have  been  met  are: 

(1)  The  actual  locations  of  the  displays  and  controls  and 
their  operational  characteristics  are  not  described  in 
HOPROC  because  they  are  irrelevant  to  how  the  operator 
uses  the  equipment.  These  data  are  supplied  at  the  time 
of  simulation  and  can  be  readily  modified  in  order  to 
simulate  different  crewstation  configurations. 

(2)  The  descriptions  of  hardware  and  operator  procedures  and 
functions  are  highly  modular  so  that  the  procedures  and 
functions  developed  for  one  crewstation  can  be  readily 
adapted  for  use  in  other  simulations. 

(3)  HOPROC  is  a  free-format,  Engl ish/FORTRAN-1 ike  language 
that  can  be  readily  interpreted  even  by  those  with  little 
familiarity  with  the  language  or  the  specific  problem 
being  simulated. 
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THE  HUMAN  OPERATOR'  PROCEDURES  (HOPROC)  LANGUAGE 


HOPROC  —  AN  ENGLISH/FORTRAN-LIKE  LANGUAGE  USED  TO  DESCRIBE  A 
CREWSTATIQN  AND  A  MISSION  TO  HOS. 


HOPROC  HAS  THREE  MAJOR  SECTIONS: 

•  A  TITLE  DECLARATIONS  SECTION 

•  A  FUNCTIONS  SECTION 

t  A  PROCEDURES  SECTION 
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The  HOPROC  mission  description  has  three  major  components: 

(1 )  Title  Declarations 

(2)  Function  Definitions 

(3)  Procedure  Definitions 

The  title  declarations  assign  names  to  the  various  devices  in 
the  operator's  crewstation.  In  addition,  they  describe  certain  general 
characteristics  of  the  operator's  displays  and  controls  and  the  symbols 
that  may  appear  on  the  operator's  display  screens.  The  primary  device 
characteristics  defined  in  the  title  declarations  are  the  settings  or 
scale  factors  associated  with  the  devices.  These  device  characteristics 
declarations  enable  HOS  to  examine  the  statements  entered  by  the  analyst  in 
the  functions  and  procedures  definitions.  HOS  can  then  determine  whether 
the  analyst's  description  of  the  crewstation  and  of  the  operator's  tasks 
is  complete  and  consistent.  If  the  description  is  not  complete  and/or 
consistent,  HOS  will  indicate  to  the  analyst  where  the  crewstation  and/or 
task  descriptions  are  lacking. 

The  heart  of  the  mission  description  is  the  procedure  definitions. 
These  describe  the  tasks  that  the  operator  must  perform  in  order  to  carry 
out  his  mission,  the  effects  on  the  hardware  of  any  actions  taken  by  the 
operator,  and  the  independent  external  events  that  may  occur  during  the 
simulation  and  that  may  impact  on  the  operator's  mission. 

The  function  definitions  describe  both  the  mental  calculations 
that  the  operator  must  perform  in  order  to  carry  out  the  mission  tasks  and 
the  mathematical  calculations  that  occur  during  the  hardware  processing. 

The  title  declarations ,  functions,  and  procedures  are  defined  in 
a  HOPROC  data  deck  consisting  of  ten  sections,  which  must  be  entered  in 
the  order  shown  in  Figure  25.  However,  when  developing  a  HOS  simulation, 
one  can  rarely  write  the  code  for  each  of  the  sections  in  order  from  begin¬ 
ning  to  end.  When  working  with  an  existing  system,  one  will  usually  begin 


SETTING  SECTION 
OSTATE  SECTION 
ARGUMENT  SECTION 
DISPLAY  SECTION 
CONTROL  SECTION 
SYMBOL  SECTION 

OPERATOR  FUNCTIONS 
HARDWARE  FUNCTIONS 

HARDWARE  PROCEDURES 
OPERATOR  PROCEDURES 


TITLE  DECLARATIONS 


FUNCTION  DEFINITIONS 

PROCEDURE  DEFINITIONS 


Figure  25.  The  Sections  in  a  HOPROC  Data  Deck 
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by  identifying  all  the  displays,  controls,  and  symbols  and  defining  their 
characteristics  in  the  appropriate  sections.  Then,  the  names  of  all  the 
settings  can  be  collected  into  the  SETTING  SECTION  associated  with  the 
displays,  controls,  and  symbols. 

The  final  step  is  to  define  the  operator  functions  and  procedures 
and  the  hardware  functions  and  procedures.  Usually,  the  operator  sections 
can  be  developed  independently  from  the  hardware  sections. 

With  a  system  that  is  still  being  planned,  the  same  general 
sequence  of  HOPROC  code  development  can  be  followed,  but  the  progression 
is  less  likely  to  be  as  clear  cut. 

Therefore,  in  developing  a  simulation,  there  is  a  tendency  to 
jump  from  section  to  section.  As  we  introduce  the  HOPROC  language  to  you 
in  the  following  paragraphs,  there  will  be  a  similar  tendency.  This  may 
be  somewhat  confusing  because,  for  example,  variations  on  certain  of  the  pro¬ 
cedural  statements  will  be  introduced  at  different  times  in  the  discussion. 

In  order  to  minimize  the  potential  confusion,  we  have  indicated  in  Figure 
26  where  each  of  the  concepts  discussed  in  the  following  sections  are 
introduced.  This  index  can  also  help  you  to  locate  the  relevant  portions 
of  the  discussions  in  both  this  manual  and  in  the  HOS  Users'  Guide,  when¬ 
ever  you  have  a  question  about  HOPROC  syntax. 

Since  this  section  is  only  an  introduction  to  HOPROC,  all  the 
options  available  for  every  HOPROC  statement  type  will  not  be  described. 
Complete  details  on  the  syntax  of  each  HOPROC  statement  are  presented  in 
Volume  II  of  the  HOS  documentation  (the  HOS  Users'  Guide)  and  on  the  HOS 
Reference  Card.  The  purpose  of  this  section  is  to  provide  novice  HCS  users 
with  an  introduction  to  the  HOPROC  language  so  that  these  references  can 
be  used  more  readily.  Later  sections  will  describe  how  one  runs  HOS  and 
how  its  output  is  to  be  interpreted  --  subjects  that  are  not  covered  in 
any  detail  in  Volume  II. 
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To  be  supplied  later. 


Figure  26.  Index 
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In  the  following  sections,  some  paragraphs  are  marked  with  the 
letter  A  in  parentheses  (A).  These  paragraphs  are  for  those  wishing  to 
learn  some  of  the  advanced  features  in  HOPROC.  It  is  recomnended  that  the 
beginning  student  skip  these  sections,  since  they  are  not  relevant  to 
a  basic  understanding  of  HOPROC  or  of  the  radar  plotting  simulation. 

3.2  TITLE  DECLARATIONS 

3.2.1  Displays  and  Controls 

The  operator's  equipment  complement  is  divided  into  two  major 
functional  groups  --  displays  and  controls .*  By  a  display  we  mean  a  device 
that  conveys  a  single  item  of  information  to  the  operator.  A  control  is  a 
device  that  the  operator  uses  to  enter  a  single  item  of  information  into  the 
system  or  to  control  a  single  function.  These  definitions  obviously  encompass 
a  wide  variety  of  very  different  devices  —  gauges,  lights,  levers, 
pushbuttons,  etc.  When  a  simulation  is  run,  HOS  requires  that  explicit 
details  about  the  characteristics  of  each  display  and  control  be  supplied. 

But  in  HOPROC,  every  device  in  the  operator's  crewstation  need  only  be 
identified  as  either  a  display  or  a  control. 

HOPROC  ignores  the  fact  that  the  actual  displays  and  controls 
in  the  system  may  be  integrated  displays  and  multifunction  controls.  One 
of  the  potential  uses  of  HOS  is  the  examination  of  the  effects  of  regroup¬ 
ing  displays  or  controls  or  of  changing  control  characteristics  or  the 
displayed  information.  Therefore,  every  item  of  information  that  can 
appear  on  an  integrated  display  must  be  identified  as  a  separate  display. 
Similarly,  every  function  that  a  multifunction  control  can  perform  must 
be  called  a  separate  control.  When  the  simulation  is  run,  display  and 
control  locations  must  be  specified  and  it  is  at  this  time  the  the  devices 
can  be  described  as  co-located. 


♦Symbols,  which  are  a  special  type  of  display  are  described  in 
Sections  3.2.9  through  3.2.11. 
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DISPLAYS 


•  CONVEY  A  SINGLE  ITEM  OF  INFORMATION 

•  HAVE  A  FIXED  LOCATION 

CONTROLS 

•  USED  TO  CONTROL  A  SINGLE  FUNCTION 

•  HAVE  A  FIXED  LOCATION 


A  final  characteristic  of  a  HOS  display  or  control  is  that, 
disregarding  the  movement  of  pointers  and  such,  displays  and  controls  do 
not  move,  relative  to  the  operator. 

The  primary  display  used  in  the  P-3C  SS-3  radar  plotting  simula¬ 
tion  is  the  multipurpose  digital  display,  which  we  shall  refer  to  as  the 
RADAR-DISPLAY.  The  controls  that  will  be  used  in  the  simulation  are  the 
LOAD  switch,  the  TRACK-BALL,  and  three  of  the  momentary  contact  switches 
on  the  keyset  tray  —  the  RADAR-MODE  pushbutton,  the  ENTER-RADAR-CONTACT 
pushbutton,  and  the  HOOK-VERIFY  pushbutton  (Figure  27). 

The  words  RAOAR-DISPLAY ,  TRACK-BALL,  etc.,  are  termed  HCFRCC 
variables.  Every  display  and  control  in  the  operator's  crewstation  must 
be  given  a  unique  variable  name.  Names  can  be  of  any  length,  but  they 
must  be  unique  within  the  first  20  characters.  Names  that  consist  of 
several  English  words,  such  as  RADAR-DISPLAY  and  TRACK-BALL,  must  either 
use  a  hyphen  to  connect  the  individual  words,  or  else  the  entire  title 
must  be  enclosed  in  quotation  marks  so  that  HOS  can  recognize  that  the 
words  comprise  a  single  title. 

3.2.2  The  DISPLAY  and  CONTROL  SECTIONS 

HOPROC  title  declarations  are  organized  so  that  all  the  displays 
are  listed  consecutively,  followed  by  all  the  controls.  Each  of  these 
sections  is  introduced  by  a  card  that  identifies  the  section  as  either  the 
DISPLAY  SECTION  or  the  CONTROL  SECTION. 

3.2.3  (A)  Overriding  the  Section  Declarations 

Displays  can  be  defined  within  the  CONTROL  SECTION  by  entering 
the  keyword  DISPLAY  after  the  display  title.  Similarly,  controls  can  be 
defined  within  the  DISPLAY  SECTION  by  entering  the  word  CONTROL  after  the 
name  of  the  control . 
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CISPLiV  SECTION 

PAQAB-OISPLAY 

RADAR-SCALE 

PAOAS-CENTEB 


CONTBOL  section 
loao 

TBACX-9ALL 

PAOAB-mOOE 

mOOK-vpoIEy 

ENTEP-flAOAR-CONTACT 


SETTINGS  OFF  ON. 
SCALE  MILES 

COOWOIMATES  MILES 


SETTINGS  Dummy  ANTENNA. 

COORDINATES  INCmEa 

MOMENT  APY 

momentary 

momentary 


Figure  27.  Display  and  control  sections  for  the  radar  plotting  simulation. 
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3.2.4 


Types  of  Displays  and  Controls 

Displays  and  controls  can  be  either  discrete,  continuous,  or 


Discrete  devices  are  devices  that  have  settings',  continuous 
devices  have  values  that  are  continuous  over  a  defined  range  and  that  may 
have  a  scale  factor  associated  with  them.  Using  the  example  of  an  auto¬ 
mobile,  the  gearshift  for  an  automobile  with  a  manual  transmission  is  a 
discrete  device  with  settings  of  either  neutral,  reverse,  first,  second, 
third  (and,  perhaps,  fourth  or  fifth).  The  speedometer,  on  the  other 
hand,  is  a  continuous  device  whose  value  can  range  from  0  mph  up  to  the 
maximum  speed  of  the  automobile. 

Positional  devices  are  a  special  type  of  continuous  device. 
Specifically,  positional  devices  are  devices  that  have  a  vector  value  -- 
i.e. ,  that  have  an  X  and  7  value  simultaneously  (or  a  range  and  a  bearing, 
magnitude  and  direction,  etc.).  An  example  of  a  positional  device  is  the 
track-ball  that  is  used  to  control  the  position  of  the  cursor  on  the 
screen.  Its  value  at  any  time  can  be  represented  by  two  numbers  that 
express  the  X  and  7  components  (or  the  magnitude  and  direction)  of  the 
displacement  of  the  track-ball  from  an  initial  position. 

3.2.5  Defining  a  Discrete  Device 

When  a  discrete  display  or  control  is  being  defined,  the  names 
of  any  settings  associated  with  the  display  or  control  must  be  identified. 
This  is  done  by  following  the  name  of  the  device  with  the  word  SETTINGS 
and  the  list  of  settings.  The  list  of  settings  is  terminated  by  a  period. 
For  example,  in  the  radar  plotting  problem,  the  LOAD  switch  has  two  set¬ 
tings,  DUMMY  and  ANTENNA.  Therefore,  the  full  definition  of  the  LOAD 
switch  is 

LOAD  SETTINGS  DUMMY  ANTENNA. 
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DEVICE  TYPES 


DISCRETE  - 
CONTINUOUS 

POSITIONAL 


HAVE  SETTINGS 


—  HAVE  VALUES  THAT  ARE 
CONTINUOUS  OVER  A  RANGE 

—  MAY  HAVE  AN  ASSOCIATED 
SCALE  FACTOR 


—  HAVE  VECTOR  VALUES 

—  MUST  HAVE  AN  ASSOCIATED 
SCALE  FACTOR 


The  order  in  which  the  settings  are  listed  is  critical  for  controls  since 
HOS  uses  the  sequence  of  settings  to  determine  the  amount  of  time  that 
the  manipulation  of  a  discrete  control  will  take.  Therefore,  the  sequence 
of  settings  must  correspond  to  the  order  in  which  the  operator  passes 
through  the  settings  when  manipulating  the  control.  For  example,  if  the 
rotary  switch  shown  in  Figure  28  had  been  in  the  SS-3  operator's  crewstation, 
the  definition  of  the  control  would  have  been: 

MOOE-SELECTOR  SETTINGS  ON-LINE,  ANALOG-TEST,  MATRIX-TEST, 

REGISTRATION-TEST,  VECTOR-TEST,  TYPE- 
TEST,  FUNCTION-GENERATOR-TEST,  OFF¬ 
LINE/ANALOG.* 

For  discrete  displays,  the  order  of  the  settings  has  no  effect 
on  the  course  of  the  simulation. 

3.2.6  (A)  Omission  of  Setting  Titles 

The  sequence  in  which  the  setting  titles  appear  is  not  critical 
for  displays.  In  fact,  the  list  of  potential  settings  that  a  display 
may  have  may  be  omitted  using  the  keyword  ANY  after  the  keyword  SETTINGS. 

Use  of  the  keyword  ANY  tells  HOS  that  the  display  may  have  any  legitimate 
setting  title.  However,  use  of  this  option  is  not  recommended  because  it 
inhibits  some  of  the  error  checks  that  HOS  normally  performs.  Consequently, 
when  the  ANY  option  is  used,  there  is  an  increased  chance  of  making  an 
error  elsewhere  in  the  simulation  that  will  not  be  detected  by  HOS. 

3.2.7  Momentary  Contact  Switches 

Momentary  contact  switches  are  a  special  type  of  discrete  control. 
Depression  of  a  momentary  contact  switch  generally  activates  the  function 
performed  by  the  control;  a  second  depression  deactivates  the  function. 
Consequently,  although  a  momentary  contact  switch  is  a  discrete  control. 


*The  comma  is  optional  punctuation  that  can  be  used  in  any  HOPROC 
statement  to  improve  readability. 
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Fifluro  28.  Example  of  multi -potition  dbatu  control. 


it  doesn't  have  settings,  as  such.  The  analyst  can  identify  controls  to 
HOS  as  momentary  contact  switches  by  substituting  the  keyword  MOMENTARY 
for  the  keyword  SETTINGS  and  the  setting  list.  For  example,  in  the  radar 
plotting  problem,  the  RADAR-MODE,  ENTER-RADAR-CONTACT,  and  HOOK-VERIFY 
controls  are  all  momentary  contact  switches.  Consequently,  they  are 
defined  by  the  statements: 

RADAR-MODE  MOMENTARY 

ENTER-RADAR-CONTACT  MOMENTARY 

HOOK-VERIFY -MOMENTARY 

3.2.8  Defining  Continuous  and  Positional  Devices 

Continuous  devices  are  devices  that  can  have  continuous  values 
over  a  defined  range.  Continuous  devices  may,  optionally,  have  a  scale 
factor  associated  with  them.  The  scale  factor  is  entered  after  the  keyword 
SCALE,  which  follows  the  device  title. 

For  example,  in  the  SS-3  crewstation,  one  of  the  items  of  informa¬ 
tion  displayed  on  the  radar  display  is  the  area  covered  by  the  display. 

Since  this  information  is  displayed  in  miles,  it  could  be  defined  as: 

RADAR-SCALE  SCALE  MILES 

If  a  continuous  device  does  not  have  an  associated  scale  factor, 
the  word  SCALE  and  the  scale  factor  are  omitted. 

Positional  devices  must  have  scale  factors.  In  order  to  Identify 
than  as  positional,  the  word  COORDINATES  is  used,  instead  of  the  word  SCALE. 
For  example,  the  TRACK-BALL  is  a  positional  device.  Consequently,  its 
definition  is: 


TRACK-BALL  COORDINATES  INCHES 
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SYMBOLS 

•  CHARACTERISTICS  CONVEY  MORE  THAN  A  SINGLE 
ITEM  OF  INFORMATION 

t  LOCATION  CAN  CHANGE  THROUGH  TIME 

•  MUST  HAVE  AT  LEAST  TWO  CHARACTERISTICS 

—  EXISTENCE 
—  LOCATION 


_ w/ 


3.2.9  Symbols 

Symbols  are  a  special  type  of  display  that  differ  from  standard 
displays  in  two  significant  ways.  First,  unlike  standard  displays,  any 
particular  symbol  may  convey  move  than  a  single  item  of  information  at  a 
time.  For  example,  the  presence  of  a  symbol  on  the  RADAR-OISPLAY  indicates 
the  existence  of  an  object  such  as  a  ship  or  aircraft  in  the  real  world. 

The  shape  of  the  symbol  may  indicate  whether  it  is  a  ship  or  an  aircraft. 

The  symbol's  position  on  the  screen  indicates  the  location  of  the  object 
in  the  real  world.  If  the  real  world  object  is  moving,  then  the  position 
of  the  symbol  will  be  moving  and  its  rate  of  movement  will  indicate  how 
fast  the  real  world  object  is  moving.  Thus,  one  of  the  characteristics 
of  a  symbol  is  that  it  can  convey  more  than  a  single  piece  of  information  at 
a  time.  These  items  of  information  are  termed  the  symbol's  characteristics. 
Every  symbol  must  have  at  least  two  characteristics  --  existence  and  position. 

The  second  distinguishing  feature  of  a  symbol  is  that,  unlike 
displays  and  controls,  the  position  of  a  symbol,  relative  to  the  operator, 
can  change  over  time.  For  example,  the  position  of  the  symbol  representing 
a  moving  ship  on  the  RADAR-OISPLAY  will  change  over  time.  As  the  position 
of  the  symbol  moves,  so  too  do  the  locations  of  all  the  symbol's  character¬ 
istics.  Displays  and  controls,  on  the  other  hand,  must  always  remain  fixed, 
relative  to  the  operator. 

3.2.10  The  SYMBOL  SECTION 

Symbols  are  entered  in  a  separate  section  of  the  H0PR0C  data  deck. 
The  symbol  definitions  are  introduced  by  a  SYMBOL  SECTION  card.  The  SYMBOL 
SECTION  must  follow  the  CONTROL  SECTION.  The  SYMBOL  SECTION  for  the  radar 
plotting  problem  is  shown  in  Figure  29. 

3.2.11  Ordering  of  Symbol  Characteristic  Titles 

HOS  generally  does  not  care  about  the  order  in  which  the  names 
of  the  various  displays,  controls,  and  symbols  in  the  crewstation  are 
defined.  However,  because  of  the  fact  that  each  symbol  has  several 
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SYMflOL  SECTION 
HOOK 

_  _  hook-paOIUS 

HOOK-POSITION 

saoap-contact 


SETTINGS  ON. 

scale  inches 
COOPQINATES  miles 

2*10 

STATUS  SETTINGS  ENTERED  blank  hooked. 
POSITION  COOHOINATES  MILES 


Figure  29.  Symbol  action  for  the  radar  plotting  simulation. 


characteristics,  all  the  characteristics  for  a  symbol  must  be  defined  in 
a  group  —  they  cannot  be  scattered  throughout  the  SYMBOL  SECTION. 

Every  symbol  has  two  required  characteristics  —  its  existence 
and  its  position.  These  two  characteristics  must  be  the  first  and  last 
characteristics  defined  for  each  symbol.  Any  number  of  additional  symbol 
characteristics  may  be  defined  between  these  two  characteristics.  The 
title  that  represents  the  symbol's  existence  must  be  discrete  and  must 
have  at  least  one  setting.  The  device  title  that  represents  the  symbol's 
position  must  be  defined  with  the  word  COORDINATES  and  a  scale  factor. 

For  example,  the  HOOK  in  the  radar-plotting  problem  is  defined  as  follows: 


HOOK  SETTINGS  ON. 

HOOK-RADIUS  SCALE  INCHES 

HOOK-POSITION  COORDINATES  MILES 

Here,  the  title  HOOK  defines  the  existence  of  the  hook  on  the  display 
screen.*  HOOK-POSITION  refers  to  the  real-world  location  that  corresponds 
to  the  hook's  location  on  the  screen.  Since  real-world  coordinates  are 
measured  in  miles,  the  hook's  coordinates  are  measured  in  miles. 

The  definition  of  the  HOOK  given  above  includes  an  additional 
characteristic  of  the  HOOK  that  will  be  important  in  the  radar  plotting 
problem  —  its  radius  (HOOK-RADIUS).  Whenever  the  operator  wishes  to  hook 
a  symbol,  he  must  manipulate  the  track-ball  so  that  the  symbol  is  encircled 
by  the  HOOK.  In  order  to  be  able  to  determine  whether  a  symbol  is  encircled, 
it  is  necessary  to  know  the  hook's  radius.  This  distance  is  represented 
by  HOOK-RADIUS. 


*Since  the  HOOK  must  always  remain  on  the  screen,  its  only  allowable 
setting  is  ON. 
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The  HOOK-RADIUS  has  been  defined  with  a  scale  of  INCHES  because 
it  will  be  compared  with  the  physical  locations  of  other  symbols  on  the 
screen.  It  could  have  been  defined  with  a  scale  of  MILES  recognizing  the 
fact  that  a  HOOK-RADIUS  of  a  particular  size  corresponds  to  a  specific 
number  of  miles,  depending  on  the  scale  to  which  the  screen  is  set.  We 
chose  to  define  the  HOOK-RADIUS  as  we  did  because  of  the  fact  that  the 
number  of  miles  represented  by  the  hook-radius  will  vary  with  the  display 
scale,  whereas  the  physical  size  of  the  hook  (in  inches)  will  not  change 
when  the  display  is  rescaled. 

As  another  indication  of  the  generality  of  HOPROC,  notice  that 
it  is  not  necessary  to  specify  what  the  actual  value  of  the  HQOK-RAOIUS 
is  in  the  HOPROC  code.  The  actual  value  need  only  be  specified  when  the 
simulation  is  run.  The  HOOK-RADIUS  may  be  a  small  value,  such  that  the 
operator  will  have  to  position  the  hook  very  precisely,  or  it  could  be 
a  larger  value  that  will  not  require  such  precise  positioning.  This  is 
a  design  decision  that  will  affect  the  operator's  performance  and  HOS  can 
be  used  to  predict  what  the  consequences  of  such  decisions  will  be. 

3.2.12  (A)  Overriding  Section  Declarations 

Oi splays  and  controls  can  be  defined  in  the  SYM80L  SECTION  by 
following  the  display  or  control  title  by  the  keyword  DISPLAY  or  CONTROL. 
Similarly,  symbols  can  be  defined  In  the  DISPLAY  or  CONTROL  sections  by 
entering  the  keyword  SYMBOL  after  the  titles  of  each  of  the  symbol's 
aharaateristios . 

3.2.13  Device  Groups 

Often  there  are  groups  of  devices  that  logically  belong  together 
and  share  similar  names.  For  example,  in  a  multi-engine  aircraft,  there 
are  groups  of  displays  and  controls  that  are  identical  except  for  the  fact 
that  they  are  associated  with  different  engines.  The  radar  contact  symbols 
on  the  SS-3  operator's  radar  display  also  have  this  property. 
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Rather  than  requiring  the  separate  definition  of  each  display, 
control,  or  symbol  in  a  group  as  a  device  with  its  own  unique  set  of 
characteristics,  HOPROC  provides  a  shorthand  method  to  define  such  groups. 
First,  the  group  title  is  entered,  e.g., 

RADAR-CONTACT 

Next,  the  number  of  individual  displays,  controls,  and/or  symbols  or  symbol 
characteristics  associated  with  each  element  in  the  group  is  entered. 

For  example,  there  are  two  characteristics  associated  with  each  radar  con¬ 
tact  —  its  STATUS  and  its  POSITION.  Consequently,  the  number  of  symbol 
characteristics  associated  with  each  element  in  the  group  is  two: 

RADAR-CONTACT  2 

This  number  (the  number  of  subgroups)  is  followed  by  a  number  that  repre¬ 
sents  the  number  of  elements  in  the  group.  Thus,  if  a  maximum  of  10  radar 
contacts  can  appear  on  the  screen  at  any  one  time,  the  number  10  would  be 
entered  after  the  number  of  subgroups: 

RADAR  CONTACT  2,10 

Each  of  the  subgroup  titles  is  then  defined  as  if  it  referred  to  an 
individual  display,  control,  and/or  symbol: 

RADAR-CONTACT  2,10 

STATUS  SETTINGS'  ON  OFF  ENTERED  HOOKED. 

POSITION  COORDINATES  MILES 

HOS  will  automatically  generate  titles  for  each  subgroup  and 
each  element  in  the  group.  The  titles  will  be  formed  by  concatenating 
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DEVICE  GROUPS 


USED  TO  IDENTIFY  LOGICALLY  GROUPED  DEVICES  THAT 
SHARE  SIMILAR  NAMES, 


DURING  THE  SIMULATION,  HOS  WILL  AUTOMATICALLY 
REFERENCE  THE  DESIGNATED  ELEMENT 
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(i.e. ,  combining)  the  group  title  with  the  subgroup  title  and  with  the 
element  numbers.  For  example,  the  titles  that  will  be  formed  for  the  group 
defined  above  will  be: 

RADAR-CONTACT-STATUS 
RADAR-CONTACT-1 -STATUS 

RADAR-CONTACT- 1 0-STATUS 
RADAR-CONTACT-POSITION 
RADAR-CONTACT-1 -POSITION 

RADAR-CONTACT-1 0-P0SITI0N 

During  the  simulation,  the  analyst  can  refer  to  the  subgroup 
titles  without  specifying  a  particular  element  number  —  e.g., 

READ  THE  RADAR-CONTACT-POSITION. 

HOS  will  automatically  perform  the  appropriate  actions  on  the  specific 
element  that  has  been  determined  to  be  "of  interest"  at  that  particular 
point  in  the  simulation. 

Note  that  the  subgroups  within  the  RADAR-CONTACT  group  are  symbols 
defined  within  a  group  definition.  As  with  other  symbols,  the  first 
symbol  characteristic  must  be  discrete  and  the  last  must  be  positional. 

In  this  case,  no  additional  characteristics  were  defined. 

3.2.14  The  SETTING  SECTION 

As  the  settings  associated  with  each  display,  control,  or  symbol 
are  determined,  the  setting  titles  must  be  collected  into  a  SETTING  SECTION. 
The  SETTING  SECTION  is  entered  prior  to  the  DISPLAY,  CONTROL,  and  SYMBOL 
SECTIONS.  Even  though  several  different  displays,  controls,  and  symbols 
may  share  the  same  setting  title,  the  title  need  be  entered  only  once  in 


setting  section 
antenna 
blank 

DUMMY 

ENTERED 
HOOKED 
OFF  ON 


Figure  30.  Setting  taction  for  tha  radar  plotting  simulation. 


TOO 


the  SETTING  SECTION.  The  SETTING  SECTION  for  the  SS-3  radar  plotting 
problem  is  shown  in  Figure  30. 

3.2.15  (A)  Ordinals 

Often,  a  display,  control,  or  symbol  will  have  settings  that 
are  numeric  values.  For  example,  the  VHF  channel  selector  on  a  television 
is  a  control  that  has  the  settings  2  through  13  and  UHF.  If  such  a  con¬ 
trol  was  being  defined,  the  ORDINAL  keyword  couldbeused  to  eliminate  the 
need  to  list  all  the  numeric  values  in  the  SETTING  SECTION  and  in  the  list 
of  device  settings.  Using  the  keyword  ORDINAL  instead  of  the  word  SETTINGS 
Tn  the  device  definition  tells  HOS  that  the  device  has  a  sequential  list 
of  numeric  settings.  For  example,  defining  the  channel  selector  as: 

CHANNEL-SELECTOR  ORDINAL  2  TO  13,  UHF. 

is  equivalent  to  defining  it  as: 

CHANNEL-SELECTOR  SETTINGS  2,3,4,5,6,7,8,9,10,11,12,13,  UHF. 

and  including  the  settings  2,3,4,5,6,7,8,9,10,11,12,13,  and  UHF  In  the 
SETTING  SECTION.  In  the  former  case,  only  the  setting  UHF  needs  to  be 
listed  in  the  SETTING  SECTION. 

3.3  THE  PROCEDURE  DEFINITIONS 

The  preceding  sections  have  described  the  major  features  of 
the  HOPROC  title  declarations.  In  an  actual  HOPROC  data  deck,  the  functions 
are  defined  immediately  after  the  title  declarations.  However,  in  creating 
a  HOS  simulation,  it  is  usually  much  more  natural  to  develop  the  operator 
and  hardware  procedures  before  creating  the  operator  and  hardware  functions. 
Therefore,  we  will  describe  the  features  of  the  procedure  definitions 
before  discussing  the  functions. 
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OEEINE  T“£  MISSION. 

pepeop*  pahar-blot. 
ENO. 


oeetne  the  ppoceoupe  ro  saoaj-plot. 

iNAflLE  Tm£  PaOAW-OISPLAY. 

:•  ANY  PAOAP-CONTACT-STaTUS  IS  NOT  £NTE«tO  Ir»£N 
£NT£P:  OESIGNATE  IT  AS  THE  baQap-COnTaCT  QE  INTEREST: 

HOVE  tHf  hOO^-POSI riOH  TO  Th£ 

PAOAP-COMTACT-POS ITIOm  s 
HEPOESS  hOO*-v£PIE/; 

OEBPESS  EmTEP-PaOAH-conTACT. 

IE  AN0Th£9  BAOAP-CONTACT-STATUS  IS  NOT  E.mT£P£3 
Then  GO  TO  ENTER  NOW. 

ENfl. 


OEFTnE  Th£  PROCEDURE  TO  ENABLE  Th£  PaOAP-O ISPLAY . 
TURN  LOAO  TO  ANTENNA. 

ENO. 


OEEINE  the  PPOCEOUPC  TO  AO JUST  TM£  hcOK-POS I T IOn. 
CHECK:  PE AO  THE  HOOK-POSITION. 

IE  IT  IS  OK  THEN  ENO. 

OETEPMINE  Tm£  TPACK-«4LL-P0SITI0n. 

HOVE  THE  TRACK-BALL  TO  Tn£  RESULT. 

IF  Thf  paTE  OE  THE  TPACK-8ALL  IS  NOT  O.n  InChES 
THEN  WAIT. 

GO  TO  CHECK  NON. 


OEEINE  the  PPOCEOUPE  to  ENABLE  mOOk-vEWIEy. 

AO JUST  THE  HOOK -POSIT ION. 

ENO. 


OEEINE  THE  PPOCEOUPE  TO  ENABLE  £NTEB-«AOaP-COnTaCT . 
OEPPESS  RAOAR-hOOE. 


Figur»  31.  Opwraor  procadurws  tar  ttw 


plotting  simulation. 


There  are  two  parts  to  the  procedure  definitions.  One  part 
describes  the  operator  procedures  —  the  tasks  to  be  performed  by  the 
operator.  The  second  part  describes  the  hardware  procedures  —  the  hard¬ 
ware  consequences  of  the  actions  taken  by  the  operator  and  the  independent 
behavior  of  other  systems  being  simulated.  The  rules  governing  statement 
syntax  are  almost  identical  in  both  sections.  Therefore,  in  the  discus¬ 
sion  to  follow,  the  characteristics  of  the  operator  procedures  will  be 
described  first.  Differences  between  the  operator  and  hardware  procedures 
will  then  be  described. 

3.4  THE  OPERATOR  PROCEDURES 

The  operator  procedures  for  the  radar  plotting  problem  are  shown 
in  Figure  31.  The  operator  procedures  are  introduced  by  an  OPERATOR 
PROCEDURES  statement.  This  statement  is  followed  by  the  procedures  them¬ 
selves.  Each  procedure  is  introduced  by  a  DEFINE  statement  and  continues 
until  the  next  DEFINE  statement.  Procedures  can  be  defined  in  any  order. 

3.4.1  The  DEFINE  Statement 

The  first  statement  in  the  radar  plotting  operator  procedures  is 
OEFINE  THE  MISSION. 

This  statement  is  an  example  of  a  HOPROC  DEFINE  statement.  The 
DEFINE  statement  begins  with  the  word  DEFINE  and  ends  with  a  period.  In 
between,  there  must  be  a  procedure  name,  chosen  by  the  analyst.  In  this 
case,  the  name  MISSION  was  chosen  as  the  name  of  the  procedure. 

The  use  of  the  name  MISSION  as  the  name  of  this  procedure  has  a 
special  significance  to  HOS  —  specifically,  it  announces  to  HOS  that  this 
is  the  procedure  that  will  control  the  simulation.  When  the  simulation 
begins,  HOS  looks  for  a  procedure  named  MISSION  in  the  set  of  operator 
procedures.  If  it  finds  one,  that  procedure  is  used  as  the  controlling 
procedure.  If  HOS  doesn't  find  a  procedure  named  MISSION,  then  it  assumes 


DEFINE  STATEMENT 


INTRODUCES  A  PROCEDURE  DEFINITION. 

PROCEDURES  CAN  BE  DEFINED  IN  ANY  ORDER. 

MISSION  SHOULD  BE  THE  FIRST  OPERATOR 
PROCEDURE. 

THE  DEFINE  STATEMENT  IS  NON-EXECUTABLE  - 
l.E.j  IT  DOES  NOT  RESULT  IN  ANY  OPERATOR 
ACTIONS. 


PERFORM  STATEMENT 


PLACES  THE  NAMED  PROCEDURE  ON  THE  ACTIVE  PROCEDURE 
LIST 

BEGINS  THE  EXECUTION  OF  THE  NAMED  PROCEDURE 

INHIBITS  THE  CONTINUATION  OF  THE  CURRENT  PROCEDURE 
UNTIL  THE  NAMED  PROCEDURE  IS  COMPLETED 


ACCOMPLISH  IS  A  SYNONYM  FOR  PERFORM. 
PERFORM  VERB  CAN  BE  OMITTED. 


that  the  first  operator  procedure  is  the  main  procedure,  no  matter  what 
its  name  is. 


The  word  THE  in  the  DEFINE  statement  is  an  example  of  a  dis¬ 
regarded  word.  These  are  words  that  are  completely  ignored  by  HOS,  but 
can  be  used  to  improve  the  readability  of  the  procedure.  The  list  of 
disregarded  words  is  shown  in  Figure  32. 

3.4.2  The  PERFORM  Statement 

The  first  executable  statement  in  PROCEDURE  MISSION  is  an  example 
of  a  PERFORM  statement.  The  PERFORM  statement  identifies  a  procedure, 
defined  elsewhere  in  the  procedures  section  that  must  be  executed  before 
the  current  procedure  can  be  continued.  In  this  case,  the  statement: 

PERFORM  RADAR-PLOT. 

says  that  the  HOS  operator  is  not  allowed  to  continue  with  the  MISSION  pro¬ 
cedure  until  the  RADAR-PLOT  procedure  has  been  completed. 

The  word  PERFORM  is  actually  unnecessary.  The  instruction  would 
have  been  understood  equally  well  by  HOS  if  the  PERFORM  had  been  omitted. 

In  that  case,  the  instruction  would  have  been  simply: 

RADAR-PLOT. 

The  word  ACCOMPLISH  can  be  used  as  a  synonym  for  the  word  PERFORM 
and  any  disregarded  words  can  be  inserted  in  the  statement  without  changing 
its  meaning.  Thus,  the  statements: 

ACCOMPLISH  RADAR-PLOT. 
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A 

THE 

AN 

TO 

AT 

ROUTINE 

IN 

SUBROUTINE 

OF 

PROCEDURE 

Figure  32.  Disregarded  Words 
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and 


ACCOMPLISH  THE  PROCEDURE  TO  RAOAR-PLOT. 
mean  exactly  the  same  thing  as: 

PERFORM  RADAR-PLOT. 

3.4.3  (A)  The  START  Statement 

If  it  is  not  necessary  for  the  operator  to  complete  a  procedure 
before  going  on  to  the  next  statement,  then  the  word  START  (or  one  of  its 
synonyms  —  COMMENCE,  BEGIN,  INITIATE,  or  ACTIVATE)  is  used  instead  of  the 
word  PERFORM.  For  example: 


START  RADAR-PLOT. 

would  tell  HOS  to  put  the  radar-plotting  procedure  on  the  list  of  active 
procedures  and  to  execute  it  as  time  is  available. 

3.4.4  (A)  The  COMPLETE  Statement 

If  a  particular  procedure  has  been  placed  on  the  active  procedure 
list  by  a  START  statement  and  at  a  later  point  it  must  be  completely  executed 
before  continuing  with  the  current  procedure,  then  the  verb  COMPLETE  can  be 
used.  For  example,  the  statement: 

COMPLETE  RADAR-PLOT. 

says  that,  if  the  RADAR-PLOT  procedure  is  on  the  active  procedures  list, 
then  it  must  be  completed  before  going  on  to  the  next  statement.  If  the 
procedure  is  not  on  the  active  procedures  list,  the  COMPLETE  instruction 
will  be  ignored. 
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START  STATEMENT 


i 


•  PLACES  THE  NAMED  PROCEDURE  ON  THE  ACTIVE  PROCEDURE 
LIST 

•  SYNONYMS  —  COMMENCE./  BEGIN/  INITIATE/  ACTIVATE 


COMPLETE  STATEMENT 


•  FORCES  THE  NAMED  PROCEDURE  TO  BE  COMPLETED  BEFORE 
THE  CURRENT  PROCEDURE  CAN  BE  CONTINUED 


END  STATEMENT 


•  REMOVES  THE  NAMED  PROCEDURE  FROM  THE  ACTIVE  PROCEDURE 
LIST 

•  IF  THERE  IS  NO  NAMED  PROCEDURE/  THE  CURRENT  PROCEDURE 
IS  UNDERSTOOD 
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3.4.5 


The  END  Statement 

The  second  statement  in  MISSION  is  an  example  of  an  END  state¬ 
ment.  ENO  statements  are  used  whenever  execution  of  a  procedure  is  to 
be  terminated.  The  basic  format  for  the  statement  is: 

ENO  procedure-name. 

If  the  name  of  the  procedure  is  omitted,  as  in  the  example,  HOS 
automatically  understands  that  the  procedure  to  be  terminated  is  the  pro¬ 
cedure  currently  being  defined  —  in  this  case  MISSION.  Since  the  END 
statement  is  the  last  statement  in  MISSION,  it  could  also  have  been  omitted 
entirely.  HOS  would  have  automatically  known  that  when  the  RADAR-PLOT 
procedure  had  been  completed,  the  MISSION  was  over. 

3.4.6  The  ENABLE  Procedures 

The  RADAR-PLOT  procedure  referenced  in  MISSION  is  shown  in  Figure 
33.  The  first  statement  in  this  procedure  is: 

ENABLE  THE  RADAR-DISPLAY. 

This  statement  is  actually  a  special  form  of  the  PERFORM  statement.  It 
says  that  there  is  a  procedure  named  ENABLE  THE  RADAR-DISPLAY  that  is  to  be 
executed  before  the  RADAR-PLOT  procedure  can  be  continued.  The  function  of 
an  ENABLE  procedure  is  to  activate  a  display  or  control  so  that  the  informa¬ 
tion  presented  on  the  display  can  be  read  by  the  operator  or,  in  the  case 
of  a  control,  so  that  a  control  manipulation  can  be  performed.  As  with  a 
standard  PERFORM  statement,  the  ENABLE  procedure  must  be  executed  before 
the  current  procedure  can  be  continued.  However,  if  the  display  or  control 
named  in  the  ENABLE  statement  is  already  active,  HOS  will  automatically 
ignore  the  ENABLE  statement. 
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fNTPO: 


oertNf  the  procedure  to  raoah-©lot. 
enable  the  waoaR-OISPL*t. 

IF  ANY  PAOAO-CONTACT-STATUS  IS  NOT  £NT£WtD  Th£n 

DESIGNATE  it  as  The  9AGAS-C0NTACT  of  INTEREST; 
move  Th e  hOOK -POSIT ION  TO  Tw€ 
QaOAB-CONTaCT-POSITION* 
oeopEEs  hoOK-vEojfy: 

DEPRESS  ENTEP-PAOAH-COwTArr. 

IF  ANOTHER  P AO aH-CONT act-status  is  not  ENTERED 
THFn  00  TO  ENTER  nqw. 

FnO. 


Rgum  33.  TJw  RADAR-PLOT  preeadura. 
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ENABLE  PROCEDURES 

--  "activate"  displays  or  controls 

—  ENABLE  INFORMATION  TO  BE  READ  FROM  DISPLAYS 
OR  CONTROL  MANIPULATIONS  TO  BE  PERFORMED 


ENABLE  STATEMENTS 

—  SPECIAL  FORM  OF  THE  PERFORM  STATEMENT 
—  ARE  IGNORED  IF  THE  DISPLAY  OR  CONTROL  IS  ALREADY 
ACTIVE 


ALTER  STATEMENT  FOR  DISCRETE  CONTROLS 


CAUSES  THE  OPERATOR  TO  CHANGE  THE  SETTING  OF  A  CONTROL  TO 
A  SPECIFIED  SETTING 


INITIATES  RECALL,  INFORMATION  ABSORPTION,  ANATOMY  MOVEMENT, 
AND  CONTROL  MANIPULATION  MICRO-MODELS 


RESULTS  IN  THE  EXECUTION  OF  A  HARDWARE  PROCEDURE  ASSOCIATED 
WITH  THE  CONTROL 


SYNONYMS  FOR  ALTER  —  TURN,  CHANGE,  MODIFY,  VARY,  MANIPULATE, 

PUSH,  PRESS,  DEPRESS,  PULL,  TWIST,  SET, 
ENGAGE,  SWITCH,  PLACE,  MOVE,  INCREASE, 
DECREASE 
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3.4.7  The  ALTER  Statement  for  Discrete  Controls 

The  procedure  to  ENABLE  THE  RADAR-DISPLAY  consists  of  a  single 

statement: 


TURN  LOAD  TO  ANTENNA. 

This  statement  is  an  example  of  an  ALTER  statement  for  a  discrete 
control.*  The  statement  tells  the  HOS  operator  to  change  the  LOAD  switch  from 
its  current  setting  to  the  setting  ANTENNA.  If  the  LOAD  switch  is  already  in 
the  ANTENNA  position,  the  HOS  operator  will  ignore  the  instruction;  if  it 
is  in  the  DUMMY  position  (as  it  will  be  at  the  beginning  of  the  simulation), 
the  operator  will  move  his  hand  to  the  control  and  switch  it  to  the  desired 
setting,  ANTENNA. 

Changing  the  control's  setting  will  have  effects  on  the  hardware 
which  will  be  described  later  when  the  hardware  procedures  are  discussed. 

For  now,  we  will  simply  assume  that  changing  the  control's  setting  will 
activate  the  radar  display,  thereby  enabling  the  operator  to  read  the 
positions  of  the  radar-contacts  appearing  on  the  display  screen. 

3.4.8  The  IF  ANY  Statement 

The  next  statement  in  RADAR-PLOT: 

IF  ANY  RADAR-CONTACT-SYMBOL  IS  NOT  ENTERED  THEN  ... 
is  an  example  of  an  IF  statement.  The  general  format  for  an  IF  statement  is: 

IF  condition  THEN  statement(s) . 


*The  words  TURN,  CHANGE,  MODIFY,  VARY,  MANIPULATE,  PUSH,  PRESS,  DEPRESS, 
PULL,  TWIST,  SET,  ENGAGE,  SWITCH,  PLACE,  MOVE,  INCREASE,  and  DECREASE  are 
all  synonyms  for  ALTER. 
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IF  ANY  STATEMENT 


CAUSES  THE  OPERATOR  TO  SEARCH  THROUGH  A  GROUP  OF 
DEVICES  LOOKING  FOR  ONE  THAT  SATISFIES  THE  TEST 
CONDITIONS. 


SELECTED  ELEMENT  WILL  BE  AUTOMATICALLY  REFERENCED 
WITHIN  THE  CURRENT  PROCEDURE  OR  ANY  ENABLE  PROCEDURE 
INVOKED  BY  THE  CURRENT  PROCEDURE. 
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In  this  case,  the  "condition"  is: 


ANY  RADAR-CONTACT-SYMBOL  IS  NOT  ENTERED 

This  is  a  complex  type  of  condition  referred  to  as  an  "IF  ANY" 
condition.  IF  ANYs  are  used  whenever  the  analyst  wishes  to  search  through  a 
group  of  items,  looking  for  a  specific  one  that  satisfies  the  test  condition. 
In  this  particular  case,  the  HOS  operator  is  being  told  to  search  through 
the  symbols  in  the  RADAR-CONTACT  group  looking  for  one  that  has  not,  as  yet, 
been  entered.  The  HOS  operator  will  look  at  each  radar  contact  in  turn, 
searching  for  the  first  contact  that  has  not  been  entered.  If  one  is  found, 
he  will  perform  the  actions  specified  in  the  statements  that  follow  the 
keyword  THEN.  If  one  is  not  found,  the  operator  will  ignore  the  statements 
in  the  THEN  clause  and  continue  execution  at  the  first  statement  after  the 
period  that  terminates  the  THEN  clause. 

3.4.9  The  DESIGNATE  Statement 

If  a  radar  contact  symbol  is  found  that  has  not  been  entered, 

HOS  will  execute  the  instructions  in  the  THEN  clause  of  the  IF  statement. 

The  first  statement  following  the  keyword  THEN: 

DESIGNATE  IT  AS  THE  RADAR-CONTACT  OF  INTEREST; 

is  an  example  of  a  DESIGNATE  statement.  This  statement  "designates" 
the  element  in  the  RADAR-CONTACT  group  identified  by  the  IF  ANY  as  the 
RADAR-CONTACT  "of  interest,"  i.e.,  the  element  in  the  radar  contact  group 
to  be  used  whenever  any  reference  is  made  to  the  RADAR-CONTACT  group. 

The  DESIGNATE  statement  can  also  be  used  to  designate  a  specific 
element  (without  the  use  of  an  IF  ANY).  For  example,  if  element  three  in 
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DESIGNATE  STATEMENT 


IDENTIFIES  A  SELECTED  SROUP  ELEMENT 
AS  THE  ELEMENT  OF  INTEREST. 


PUNCTUATION 

PERIODS  —  TERMINATE  A  SENTENCE 

SEMI-COLONS  &  AND  —  CONNECT  CLAUSES  IN  THE  THEN  PORTION 

OF  AN  IF  STATEMENT 

COMMAS  —  ARE  DISREGARDED 


PARENTHESES  CAN  BE  USED  TO  DELIMIT  COMMENTS 


the  RADAR-CONTACT  group  was  to  be  used  whenever  any  of  the  items  in  the 
group  was  referenced,  the  statement: 


DESIGNATE  3  AS  THE  RADAR-CONTACT  OF  INTEREST, 
could  be  used. 

3.4.10  (A)  Scope  of  an  IF  ANY 

Within  the  procedure  in  which  an  IF  ANY  statement  is  used,  any 
references  to  the  group  being  searched  by  the  IF  ANY  will  automatically  be 
understood  to  refer  to  the  particular  element  that  satisfied  the  IF  ANY. 

In  addition,  any  ENABLE  procedure  begun  by  the  procedure  that  uses  the 
IF  ANY  and  that  references  the  group  will  also  be  automatically  assumed  to  be 
referring  to  the  group  element  chosen  by  the  IF  ANY.  However,  in  order  to 
tell  other  procedures  to  use  the  particular  element  selected  by  the  IF  ANY, 
the  element  must  be  "designated"  by  a  DESIGNATE  statement. 

3.4.11  Punctuation 

Up  to  this  point,  every  procedural  statement  that  we  have 
encountered  has  been  terminated  by  a  period.  The  statements  in  the  THEN 
clause,  however,  are  terminated  by  a  semi-colon.  The  semi-colon  is  used 
when  there  are  several  statements  in  a  THEN  clause  that  are  to  be  executed 
as  a  consequence  of  having  satisfied  the  IF  statement.  All  statements 
in  a  THEN  clause  connected  by  semi-colons  (or  by  the  conjunction  AND)  will 
be  executed  when  the  IF  is  satisfied  and  skipped  whenever  the  IF  is  not 
satisfied. 

3.4.12  The  ALTER  Statement  for  Displays  and  Symbols 
The  second  statement  in  the  THEN  clause: 

MOVE  THE  HOOK-POSITION  TO  THE  RADAR-CONTACT-POSITION; 

is  another  example  of  an  ALTER  statement.  In  this  case,  though,  the  device 
being  altered,  HOOK-POSITION,  is  a  symbol  characteristic  rather  than  a 
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ALTER  STATEMENT  FOR  DISPLAYS  AND  SYMBOLS 


CHANGES  THE  DESIRED  VALUE  OF  A  DISPLAY  OR  SYMBOL  TO  A  NEW 
VALUE. 


PLACES  THE  ADJUST  PROCEDURE  FOR  THE  DISPLAY  OR  SYMBOL  ON 
THE  ACTIVE  PROCEDURE  LIST. 


DOES  MI  RESULT  IN  AN  IMMEDIATE  CHANGE  TO  THE  ACTUAL  VALUE 
OF  THE  DISPLAY  OR  SYMBOL. 
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control.  Because  HOOK-POSITION  is  a  symbol  characteristic,  this  ALTER 
statement  is  significantly  different  from  the  ALTER  statement  (TURN  LOAD 
TO  ANTENNA)  that  we  encountered  previously.  This  is  because,  unlike  con¬ 
trols,  displays  and  symbols  cannot  be  altered  directly.  Rather,  when  the 
desired  value  of  a  display  or  symbol  is  to  be  changed,  a  procedure  must 
be  invoked  that  uses  a  control  to  change  the  actual  value  of  the  display 
or  symbol.*  The  procedure  that  is  invoked  is  termed  an  adjust  procedure. 
Figure  34  is  an  example  of  such  a  procedure  —  the  procedure  to  ADJUST  THE 
HOOK-POSITION.  When  the  ALTER  statement: 

MOVE  THE  HOOK-POSITION  TO  THE  RADAR-CONTACT-POSITION. 

is  encountered,  this  ADJUST  procedure  is  placed  on  the  active  procedure 
list,  to  be  executed  when  time  is  available.  ADJUST  procedures  placed  on 
the  active  procedure  list  by  an  ALTER  statement  are  not  executed  i (mediately. 
Consequently,  the  hook  will  not  move  to  the  position  of  the  radar  contact 
immediately.  Rather,  it  will  be  moved  only  when  the  operator  has  time 
available,  or  when  some  other  instruction  is  executed  that  forces  the  pro¬ 
cedure  to  be  executed. 


*Any  of  the  device  parameters  (DESIRED,  ESTIMATED,  CRITICALITY,  STATE, 
UPPER,  LOWER,  HA8 -STRENGTH,  TITLE,  ACTUAL,  DESIGNATED,  RATE,  TIME,  XVALUE, 
and  YVALUE)  can  be  referenced  in  an  ALTER  statement,  e.g.: 

CHANGE  THE  UPPER  (LIMIT)  OF  THE  ALTIMETER  TO  1000  FEET. 

The  current  remarks  apply  only  to  the  DESIRED  value,  which  is  the  parameter 
most  frequently  referenced  in  the  operator  procedures  and  the  parameter 
assumed  by  default  when  no  parameter  is  specified  for  the  device  title 
that  immediately  follows  the  ALTER  verb. 
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CHECK  J 


(DEFINE  THE  BOOCEOUSE  TO  ADJUST  The  HOOK-POSITiON. 

BE 40  The  hook -posit ION. 

IE  IT  IS  Ok  T-.EN  END. 

OETE0mINE  The  THAC* -flAU- -POSITION. 

HOVE  THE  TPaCK-^alL  TO  Th£  RESULT. 

IP  the  SATE  OF  TH£  TOaCk-SaLL  IS  NOT  0.0  INCHES 
Then  ha  IT. 

00  TO  CHECK  NO'*. 


Fi*ir«  34.  Tho  procedure  to  ADJUST  THE  HOOK-POSITION. 


3.4.13  The  ALTER  Statement  for  Momentary  Contact  Switches 

Momentary  contact  switches  are  discrete  controls  that  have  no 
specific  settings  to  which  they  can  be  set.  Consequently,  the  ALTER  state' 
ment  for  a  momentary  contact  switch  reduces  to  simply: 

DEPRESS  control . 

where  control  is  the  name  of  the  momentary  contact  switch.  The  next  two 
statements  in  the  RADAR-PLOT  procedure: 

DEPRESS  HOOK-VERIFY; 


and 


DEPRESS  ENTER- RADAR-CONTACT. 

are  examples  of  ALTER  statements  for  momentary  contact  switches. 

3.4.14  Implicit  Invocation  of  ENABLE  Procedures 
The  statements: 


DEPRESS  HOOK-VERIFY; 


and 


DEPRESS  ENTER-RADAR-CONTACT. 

share  an  interesting  characteristic  —  namely,  that  the  actions  cannot  be 
performed  because  certain  prerequisites  have  not  been  satisfied.  In  par¬ 
ticular,  in  order  for  the  operator  to  successfully  perform  the  HOOK-VERIFY 
function,  he  must  have  first  moved  the  hook  to  its  desired  position.  ENTER 
RADAR-CONTACT,  on  the  other  hand,  cannot  be  depressed  until  after  the  HOOK- 
VERIFY  function  has  been  performed  and  until  after  the  RADAR-MODE  switch 
has  been  depressed. 
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IMPLICITLY  INVOKED  ENABLE  PROCEDURES 

EXECUTED  IN  ORDER  TO  ENABLE  A  CONTROL  MANIPULATION  TO  BE 
PERFORMED. 

DESCRIBE  THE  PREREQUISITES  THAT  MUST  BE  SATISFIED. 
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The  ENABLE  procedure  for  HOOK-VERIFY  (Figure  35)  ensures  that 
the  operator  will  position  the  hook  over  the  radar  contact  before  depres¬ 
sing  HOOK-VERIFY.  The  ENABLE  procedure  for  ENTER -RADAR-CONTACT  (also  shown 
in  Figure  35)  ensures  that  the  operator  will  depress  the  RADAR-MODE,  thereby 
activating  the  radar-matrix  subfunctions,  before  depressing  ENTER- RADAR- 
CONTACT.  These  procedures  will  be  automatically  invoked  by  HOS  before  each 
control  is  depressed.  They  are,  therefore,  said  to  be  implicitly  invoked 
ENABLE  procedures. 

The  statements  in  the  two  ENABLE  procedures  are  similar  to  some 
of  the  statements  that  have  been  discussed  above.  For  example,  the  state¬ 
ment: 


DEPRESS  RADAR-MODE. 

in  ENABLE  ENTER -RADAR -CONTACT  is  another  example  of  an  ALTER  statement  for 
a  discrete  control  and  the  statement: 

ADJUST  THE  HOOK-POSITION- 

in  ENABLE  HOOK-VERIFY  is  another  special  form  of  the  PERFORM  statement. 

In  the  case  of  ADJUST  THE  HOOK-POSITION,  however,  the  procedure  to  be 
executed,  ADJUST  THE  HOOK-POSITION,  had  already  been  placed  on  the  active 
procedure  list  by  the  statement: 

MOVE  THE  HOOK-POSITION  TO  THE  RADAR-CONTACT-POSITION. 

The  statement: 


ADJUST  THE  HOOK-POSITION. 

in  ENABLE  HOOK-VERIFY  ensures  that  the  procedure  will  be  executed  at  once. 
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OFFICE  ThE  POOCEOUOg  TO  ENABLE  hOOk-</FPIFY. 

AOJUST  The  hOOk-HOSITIOn. 

E'in. 

nEFlNE  Th£  PPOCE0UPE  ro  ENASUt  E*TE»-RauaR-COnTaCT. 
OEPPESF  BAOAP--OOF. 


Fiqura  35.  77»  ENABLE  proeadun  far  HOOK- VERIFY  and  ENTER-R  ADAR-CONT ACT . 


124 


3.4.15  (A)  MONITOR  and  DISABLE  Procedures 

We  have  encountered  two  special  types  of  operator  procedures  so 
far  --  ENABLE  procedures  and  ADJUST  procedures.  There  are  two  othp  special 
types  of  operator  procedures  --  MONITOR  procedures  and  DISABLE  procedures. 
DISABLE  procedures  are  simply  the  reverse  of  ENABLE  procedures  —  they 
deactivate  devices.  However,  unlike  ENABLE  procedures,  DISABLE  procedures 
are  not  implicitly  invoked  by  other  statements. 

MONITOR  procedures  are  simply  ADJUST  procedures  that  are  to  be 
periodically  executed  in  order  to  keep  a  display  or  control  at  some  desired 
value.  MONITOR  procedures  are  placed  on  the  active  procedure  list  by  a 
MONITOR  statement.  For  example,  the  statement: 

MONITOR  THE  ALTIMETER. 

would  place  a  procedure  named  MONITOR  THE  ALTIMETER  (or  ADJUST  THE  ALTIMETER) 
on  the  active  procedure  list  to  be  periodically  executed  until  removed  from 
the  active  procedure  list  by  an  END  statement. 

3.4.16  The  IF  ANOTHER  Statement 
The  IF  ANY  statement: 

IF  ANY  RADAR-CONTACT-SYMBOL  IS  NOT  ENTERED  THEN  ... 

identified  the  first  element  in  the  RADAR-CONTACT  group  that  satisfied  the 
specified  condition.  The  IF  ANOTHER  statement: 

IF  ANOTHER  RADAR-CONTACT-SYMBOL  IS  NOT  ENTERED  THEN  . . . 

continues  the  search,  looking  for  the  next  element  in  the  group  that  satisfies 
the  test  condition. 
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MONITOR  PROCEDURES 

—  ADJUST  PROCEDURES  THAT  ARE  TO  BE  EXECUTED  PERIODICALLY 


-  PLACED  ON  ACTIVE  PROCEDURE  LIST  BY  A  MONITOR  STATEMENT 


DISABLE  PROCEDURES 

~  deactivate  a  display,  control,  or  symbol,  thereby 

REQUIRING  AN  ENABLE  PROCEDURE  TO  BE  EXECUTED  BEFORE 
THE  DISPLAY  OR  SYMBOL  CAN  BE  READ  OR  THE  CONTROL 
MANIPULATED 


EXECUTED  THROUGH  THE  USE  OF  A  DISABLE  STATEMENT 
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3.4.17  The  GO  TO  Statement 

The  GO  TO  statement  transfers  control  to  another  statement  else¬ 
where  in  the  current  procedure.  The  statement  to  which  control  is  to  be 
transferred  must  be  identified  by  a  statement  label.  The  statement  label 
is  a  HOPROC  variable  that  precedes  the  statement  with  which  it  is  associated. 
The  label  must  be  followed  by  a  colon  ( : )  to  identify  it  as  a  label.  For 
examDle,  the  GO  TO  statement  in  the  RADAR-PLOT  procedure: 

GO  TO  ENTER. 

transfers  control  to  the  statement  identified  by  the  label  ENTER  (the 
DESIGNATE  statement).  Transfers  can  only  be  made  to  labeled  statements  in 
the  same  procedure  as  the  GO  TO  statement.  GO  TO  statements  cannot  transfer 
to  statements  in  other  procedures. 

Usually,  when  a  transfer  to  another  statement  occurs,  HOS  assumes 
that  a  logically  connected  sequence  of  steps  has  been  completed.  Therefore, 
it  will  give  other  procedures  on  the  active  procedure  list  an  opportunity 
to  be  executed  before  transferring  to  the  labeled  statement.  However,  often 
the  analyst  may  not  want  the  operator  to  have  the  option  of  working  on  other 
procedures.  If  this  is  the  case,  the  analyst  can  say: 

GO  TO  label  NOW. 

The  keyword  NOW  tells  HOS  to  transfer  immediately  to  the  labeled  statement. 

No  other  procedures  will  be  allowed  to  be  executed  before  the  transfer  to 
the  labeled  statement  has  been  completed. 

3.4.18  The  READ  Statement 

The  first  statement  in  the  ADJUST  HOOK-POSITION  procedure: 

READ  THE  HOOK-POSITION. 
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GO  TO  STATEMENTS 


TRANSFERS  CONTROL  TO  ANOTHER  STATEMENT 

TRANSFER  MAY  BE  IMMEDIATE  OR  SUCH  THAT 
OTHER  PROCEDURES  MAY  INTERVENE 

STATEMENT  TO  WHICH  CONTROL  IS  TO  BE  TRANS 
FERRED  MUST  BE  IN  THE  SAME  PROCEDURE 


READ  STATEMENT 


FORCES  OPERATOR  TO  READ  INFORMATION 
SYNONYMS  ~  CALCULATE,  COMPUTE 
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is  an  example  of  a  READ  statement.  In  the  statements  discussed  so  far,  it 
has  been  assumed  that  the  operator  would  automatically  read  or  recall  what¬ 
ever  information  was  needed,  as  it  was  needed.  However,  because  these  state¬ 
ments  allowed  the  operator  to  recall  information,  the  data  could  have  been 
recalled  incorrectly.  Use, of  the  READ  statement  forces  the  operator  to 
read  the  specified  information,  rather  than  allowing  him  to  rely  on  recall. 
Thus,  it  ensures  that  the  operator  will  use  the  current  value  of  the  HOOK- 
POSITION,  rather  than  a  possibly  incorrect  remembered  value  in  determining 
whether  an  adjustment  is  necessary. 

3.4.19  The  IF...  OK  Test 
,  The  statement: 

MOVE  THE  HOOK-POSITION  TO  THE  RADAR-CONTACT-POSITION. 

in  RADAR-PLOT  established  the  RADAR-CONTACT-POSITION  as  the  desired  value 
for  the  HOOK-POSITION.  The  ADJUST  procedure  for  the  HOOK-POSITION  describes 
the  actions  that  must  be  performed  to  ensure  that  the  HOOK  has  been  moved 
to  its  desired  position.  One  way  to  test  whether  the  HOOK  is  at  its  desired 
value  is  to  use  an  "IF...  OK"  test: 

IF  THE  HOOK-POSITION  IS  OK  THEN... 

The  OK  test  compares  the  current  estimated  value  of  HOOK-POSITION 
with  upper  and  lower  limits  established  around  the  desired  value  of  the 
HOOK-POSITION  and  determines  whether  the  estimated  value  is  within  those 
limits.  If  the  estimated  value  is  within  the  limits,  then  the  test  is 
satisfied.  If  the  estimated  value  is  not  within  the  limits,  then  the  test 
fails.* 


*The  OK  test  can  also  be  specified  as: 

IF  THE  HOOK-POSITION  IS  WITHIN  LIMITS  THEN... 
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IF,..  OK  STATEMENT 


TESTS  WHETHER  A  QUANTITY  IS  WITHIN  A  DEFINED 
SET  OF  LIMITS 


LIMITS  CAN  BE  ESTABLISHED  BY  A  SET  LIMITS... 
MENT  (A  VARIANT  FORM  OF  THE  ALTER  STATEMENT) 
A  FUNCTION 


EQUIVALENT  TO 


IF...  IS  WITHIN  LIMITS  THEN.., 


STATE- 
OR  IN 


1 30 


» 


3.4.20  (A)  Limits  on  Desired  Values 

The  limiting  range  over  which  the  estimated  value  can  vary  must 
be  established  in  the  HOPROC  code,  either  within  a  procedural  statement 
or  as  part  of  one  of  the  operator  or  hardware  functions,  before  the  IF...  OK 
instruction  is  executed.  Within  the  operator  procedures,  the  limits  can 
be  set  by  an  ALTER  statement,  e.g.,  the  statement: 

SET  LIMITS  OF  ALTIMETER  TO  1000  FEET. 

will  set  the  upper  and  lower  limits  to  1000  feet  on  either  side  of  the 
current  desired  value  of  the  altimeter.  The  upper  and  lower  limit  values 
will  change  as  the  desired  value  of  the  altimeter  is  changed  in  order  to 
maintain  the  specified  relationship  to  the  desired  value.  For  example,  if 
the  desired  value  of  the  altimeter  is  25000  feet  at  the  time  the  SET  LIMITS 
statement  is  encountered,  then  the  upper  and  lower  limits  will  be  26000  and 
24000  feet  respectively.  If  the  desired  value  of  the  altimeter  is  changed 
to  30000  feet,  the  upper  and  lower  limits  will  automatically  be  changed  to 
31000  and  29000  feet  respectively,  retaining  the  1000  foot  differential 
between  the  desired  value  and  each  of  the  limiting  values. 

In  the  SS-3  radar  plotting  example,  the  HOOK-POSITION  limits  have 
been  defined  within  a  hardware  function  (HOOK-LIMITS)  rather  than  a  pro¬ 
cedural  statement.  This  was  done  because  the  limiting  values  for  the  HOOK 
are  dependent  upon  the  display  factor  and  the  size  of  the  hook  radius,  in 
a  way  that  requires  a  potentially  complex  mathematical  expression.  Since 
expressing  complex  mathematical  functions  is  much  easier  in  HOPROC  function 
statements  than  in  HOPROC  procedural  statements,  the  limits  were  defined 
in  a  function  rather  than  in  a  procedure. 

3.4.21  (A)  Use  of  the  Pronoun  IT 

The  pronoun  IT  has  been  used  in  both  the  DESIGNATE  statement 
in  RADAR-PLOT,  and  in  the  IF...  OK  statement  in  ADJUST  THE  HOOK-POSITION. 

In  the  DESIGNATE  statement,  the  IT  referred  to  the  element  in  the  RADAR- 
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THE  COMPUTE  STATEMENT 

•  INVOKES  A  FUNCTION  CALCULATION 

•  THE  RESULT  OF  THE  FUNCTION  CALCULATION  IS 
THE  HOPROC  VARIABLE  RESULT 


CONTACT  group  that  satisfied  the  IF  ANY  statement.  In  the  IF...  OK  state¬ 
ment,  the  IT  referred  to  HOOK-POSITION.  In  general,  the  pronoun  IT  refers 
to  the  first  title  following  the  introductory  verb  in  the  preceding  state¬ 
ment.  Thus,  in  the  ADJUST  THE  HOOK-POSITION  procedure,  the  statement  pre¬ 
ceding  the  IF  IT  IS  OK...  was: 

READ  THE  HOOK-POSITION. 

Since  the  title  that  followed  the  verb  READ  was  HOOK-POSITION, 
this  was  the  title  that  was  being  referred  to  by  the  pronoun  IT.  In  the 
case  of  the  DESIGNATE  statement,  the  IT  referred  to  the  RADAR -CONTACT- 
SYMBOL  that  satisfied  the  IF  ANY. 

3.4.22  Invoking  a  Function  Calculation  —  The  COMPUTE  Statement 

The  next  statement  in  the  ADJUST  THE  HOOK-POSITION  procedure: 

DETERMINE  THE  TRACK-BALL-POSITION. 

is  an  example  of  a  COMPUTE  statement.*  The  statement  is  similar  to  the 
READ  statement  discussed  previously,  except  for  the  fact  that  it  refers  to 
a  mental  calculation  that  the  operator  must  perform,  rather  than  to  an 
observable  display,  control,  or  symbol  in  the  operator's  crewstation.  The 
mental  calculation  is  the  determination  of  the  position  to  which  the  TRACK¬ 
BALL  is  to  be  moved  in  order  to  move  the  HOOK  to  its  desired  position. 

The  details  of  this  calculation  will  be  discussed  in  Section  3.5.4.  For 
now,  we  shall  simply  assume  that  the  computation  of  the  function  will 
enable  the  operator  to  determine  where  the  TRACK-BALL  is  to  be  moved.  The 
next  statement: 


MOVE  THE  TRACK-BALL  TO  THE  RESULT. 


*DETERMINE  is  a  synonym  for  COMPUTE,  as  are  CALCULATE  and  READ. 


is  an  ALTER  statement  for  a  control  (TRACK-8ALL) .  This  statement  causes 
the  operator  to  initiate  the  TRACK-BALL  manipulation.  The  keyword  RESULT 
refers  to  the  result  of  the  TRACK-BALL-POSITION  calculation. 

3.4.23  Parameters.  Positional,  Scale  Factors,  and  Wait  Conditions 

Moving  the  HOOK  to  a  specific  point  on  the  screen,  which  may 
itself  be  moving,  is  an  example  of  a  pursuit  tracking  problem.  There  are 
a  variety  of  ways  in  which  such  problems  have  been  modeled  by  those  study¬ 
ing  human  operator  performance.  Through  its  flexible  structure,  HOS  is 
capable  of  accoimwdati ng  many  of  these  models.  For  purposes  of  this  dis¬ 
cussion,  however,  we  have  chosen  to  let  the  basic  structure  of  HOS  and 
some  of  its  constructs  dictate  the  tracking  model  that  we  would  implement. 
The  model  that  we  have  chosen  to  use  is  a  discrete  model  —  the  operator 
reads  the  position  of  the  hook,  determines  an  amount  by  which  he  must  move 
the  track-ball  in  order  to  move  the  hook  to  its  desired  position,  initiates 
the  movement,  and  then  waits  until  the  movement  is  complete  before  deciding 
whether  another  movement  is  necessary.  This  final  "action"  —  waiting 
until  the  movement  is  complete  —  is  expressed  by  the  next  statement: 

IF  THE  RATE  OF  THE  TRACK-BALL  IS  NOT  0,0  INCHES  THEN  WAIT. 

When  the  movement  is  complete,  i.e. ,  when  the  statement  above  is  satisfied, 
then  the  statement: 

GO  TO  CHECK  NOW. 

is  executed.  This  statement  recycles  the  operator  through  the  statements 
that  we  have  just  discussed  until  the  IF  IT  (i.e.,  the  HOOK-POSITION)  IS  OK 
statement  is  satisfied,  at  which  time  the  ADJUST  procedure  is  terminated. 

The  statement: 

IF  THE  RATE  OF  THE  TRACK-BALL  IS  NOT  0,0  INCHES  THEN  WAIT. 
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has  a  number  of  interesting  features  that  have  not  been  encountered  in  any 
of  the  IF  statements  discussed  so  far.  These  features  are: 

•  The  explicit  use  of  parameters. 

•  The  use  of  positional  values. 

•  The  use  of  scale  factors. 

•  The  WAIT  condition. 

The  following  sections  will  deal  with  each  of  these  features  in 

detail . 

3.4.24  (A)  Explicit  Use  of  Parameters 

All  of  the  statements  that  have  been  used  so  far  have  involved 
the  implicit  use  of  parameters.  For  example,  HOS  has  automatically  under¬ 
stood  that  when  a  device  was  referenced  in  an  IF  statement,  its  estimated 
value  was  to  be  understood.  Thus,  the  other  IF  statement  in  ADJUST  THE  . 
HOOK-POSITION  could  have  read: 

IF  THE  ESTIMATED  VALUE  OF  THE  HOOK-POSITION  IS  OK  THEN  END. 

and  the  IF  ANY  statement  in  RADAR-PLOT  could  have  been: 

IF  ANY  ESTIMATED  VALUE  OF  RADAR-CONTACT-STATUS  IS  NOT  ENTERED 
THEN... 

The  IF  statement: 

IF  THE  RATE  OF  THE  TRACK-BALL... 

differs  from  these  other  IF  statements  because  of  the  fact  that  it  explicitly 
refers  to  a  parameter  associated  with  the  TRACK-BALL,  its  RATE. 
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Whenever  a  parameter  other  than  ESTIMATED,  DESIRED,  and  STATE 
is  referenced  in  an  operator  procedures  statement,  it  must  be  explicitly 
specified.  HOS  will  generally  understand  when  the  ESTIMATED,  OESIRED,  and 
STATE  parameters  are  being  referenced.  However,  it  may  be  necessary  at 
times  for  these  parameters  to  be  explicitly  identified  as  well,  when  a 
non-standard  usage  is  desired.  The  general  rules  regarding  the  use  of 
parameters  are  as  follows: 


(1)  In  an  IF  statement,  both  the  parameter  associated  with  the 
variable  Immediately  following  the  word  IF,  and  the  param¬ 
eter  associated  with  the  variable  after  the  conditional 
phrase  are  assumed  to  be  ESTIMATED  values,  unless  other¬ 
wise  specified. 

(2)  In  an  ALTER  statement,  the  parameter  associated  with  the 
variable  following  the  ALTER  is  assumed  to  be  the  OESIRED 
value;  the  parameter  associated  with  the  variable  after 
the  TO  or  BY  is  assumed  to  be  ESTIMATED  value,  unless 
otherwise  specified. 

(3)  If  the  keywords  ACTIVE  or  INACTIVE  are  used  in  an  IF 
statement  or  in  an  ALTER  statement,  the  parameter  STATE 
is  automatically  understood. 


In  the  example,  the  parameter  RATE  had  to  be  explicitly  specified 
in  order  to  override  the  ESTIMATED  VALUE  default  parameter. 


3.4.25  (A)  Positional  quantities  in  IF  and  ALTER  Statements 

In  some  of  the  IF  and  ALTER  statements  that  we  have  discussed,  we 
have  referenced  positional  variables,  e.g.,  HOOK-POSITION  and  RADAR-CONTACT- 
POSITION  in: 

MOVE  THE  HOOK-POSITION  TO  THE  RADAR-CONTACT-POSITION. 


and  HOOK-POSITION  in: 


IF  THE  HOOK-POSITION  IS  OK  THEN  END. 
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In  these  cases,  HOS  recognized  the  fact  that  the  variables  were 
positional  and  automatically  separated  the  values  of  the  variables  into 
their  X  and  Y  components.  In  the  current  IF  statement: 

IF  THE  RATE  OF  THE  HOOK-POSITION... 

we  are  referring  to  a  parameter  associated  with  the  HOOK-POSITION,  its  rate 
of  change  (RATE),  and  we  wish  to  test  the  value  of  the  RATE  against  a  specific 
numeric  value.  8ut  since  the  HOOK-POSITION  is  a  positional  quantity,  its 
rate-of-change  is  also  positional.*  Therefore,  we  must  specify  two  numeric 
values  against  which  the  X  and  Y  components,  respectively,  are  to  be  tested. 
These  two  values  are  specified  as  0,0  INCHES  in  the  test  condition. 

3.4.26  (A)  Use  of  Scale  Factors  in  Procedural  Statements 

When  devices  defined  with  an  associated  scale  factor  are  referenced 
in  procedural  statements,  HOS  will  automatically  check  to  make  sure  that 
the  scale  factors  are  compatible  and,  if  necessary,  will  apply  the  appro¬ 
priate  conversion  factors.  Thus,  if  HOOK-POSITION  and  RADAR-CONTACT-POSITION 
had  been  defined  with  different  (but  compatible)  scale  factors,  HOS  would 
automatically  have  performed  the  appropriate  conversions  when  the  statement: 

MOVE  HOOK-POSITION  TO  THE  RADAR-CONTACT-POSITION. 

was  encountered  in  the  RADAR-PLOT  procedure.  When,  as  in  the  case  of  the 
IF  statement: 

IF  THE  RATE  OF  THE  HOOK-POSITION  IS  NOT  0,0  INCHES  THEN... 

a  numeric  value  is  used  as  the  test-condition,  the  units  associated  with 
the  numeric  value  must  be  specified.  If  the  units  are  incompatible  with 


♦Only  some  of  the  parameters  associated  with  a  positional  quantity  are 
themselves  positional  —  these  parameters  are  DESIRED,  ESTIMATED,  UPPER, 
LOWER,  ACTUAL,  and  RATE. 
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OPERATOR  FUNCTIONS 


DESCRIBE  THE  OPERATOR'S  MENTAL  CALCULATIONS. 


USES  A  HYBRID  VERSION  OF  FORTRAN. 


ENABLES  THE  VALUES  OF  DISPLAYS,  CONTROLS,  AND 
SYMBOLS  TO  BE  REFERENCED  AND  COMBINED  WITH 
IMPLICIT"  KNOWLEDGE . 
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the  units  associated  with  the  device  being  referenced,  or  if  no  units  are 
specified,  HOS  will  issue  an  error  message. 


In  the  case  of  the  RATE  parameter,  the  numeric  value  should  be 
in  "units  per  second,"  (e.g.,  INCHES  PER  SECOND)  rather  than  simply  "units," 
since  the  RATE  parameter  is  a  time  derivative.  However,  the  HOPROC  syntax 
processor  does  not  recognize  the  phrase  PER  SECOND.  Therefore,  it  should 
not  be  used. 

3.4.27  (A)  The  WAIT  Clause 

Rather  than  specifying  a  statement  or  set  of  statements  to  be 
executed  when  the  condition  in  an  IF  statement  is  satisfied,  a  WAIT  clause 
can  be  used  to  indicate  that  nothing  more  is  to  be  done  in  the  current 
procedure  until  the  condition  being  tested  by  the  IF  statement  has  been 
satisfied.  The  WAIT  clause  enables  the  HOS  operator  to  work  on  other  pro¬ 
cedures  while  waiting  for  the  condition  to  be  satisfied.  HOS  will  periodic¬ 
ally  check  the  condition  and  will  continue  execution  of  the  procedure  when 
the  condition  is  satisfied. 

3.5  OPERATOR  FUNCTIONS 

Operator  functions  describe  the  mental  calculations  that  the 
operator  is  to  perform  using  the  information  available  from  his  displays  and 
controls.  In  the  radar  plotting  procedures,  a  single  operator  function, 
TRACK-BALL-POSITION,  is  used.  This  function  calculates  the  position  to 
which  the  operator  wishes  to  move  the  track-ball  in  order  to  move  the  hook 
to  its  DESIRED  value.  This  calculation  requires  the  operator  to  combine 
an  estimate  of  the  current  position  of  the  HOOK  with  the  desired  position  for 
the  HOOK,  and  with  some  implicit  knowledge  of  the  display/control  relation¬ 
ship  between  a  TRACK-BALL  movement  and  a  change  in  the  HOOK's  position. 

Since  descriptions  of  calculations  like  this  can  become  extremely  complex, 
it  is  not  very  efficient  to  use  English-like  statements  to  describe  the 
calculation.  Therefore,  HOPROC  uses  a  special  hybrid  version  of  one  of  the 
standard  mathematical  computer  languages,  FORTRAN,  to  express  function 
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TQACK-AALL-POSITTON 
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COMPUTE  OESIPED  TPaCK  AALL  POSITION  -»ASFO  On  SCREEN  SCALE  FACTOR 
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Rqura  36.  The  TRACX-BALL-PCS1T10N  operator  function. 
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calculations.  This  hybrid  FORTRAN  enables  potentially  complex  mathematical 
relationships  between  HOPROC  variables  to  be  expressed  concisely,  while 
enabling  the  full  computational  power  of  FORTRAN  to  be  used. 


Figure  36  is  an  example  of  an  operator  function  --  specifically, 
the  operator  function  that  defines  the  TRACK-BALL-POSITION  calculation 
referenced  in  the  operator  procedure  ADJUST  THE  HOOK-POSITION.  If  you  are 
familiar  with  FORTRAN,  you  will  notice  the  resemblance  between  the  H0PR0C- 
FORTRAN  statements  and  standard  FORTRAN.  Even  if  you  are  not  familiar 
with  FORTRAN,  you  will  notice  that  the  HOPROC-FORTRAN  statements  are  very 
similar  to  standard  mathematical  equations.  In  general,  all  the  standard 
rules  of  FORTRAN  apply  to  the  coding  of  operator  functions.  There  are 
some  special  characteristics  of  HOPROC-FORTRAN  that  make  it  different  from 
standard  FORTRAN.  These  differences  are  explained  in  the  following  sections. 

3.5.1  Definition  of  a  Function 

There  may  be  many  operator  functions  defined  in  a  single  simula¬ 
tion  althougn  the  radar  plotting  simulation  uses  only  one.  Each  function 
ends  with  a  line  of  code  that  includes  the  name  of  the  function,  enclosed 
in  quotation  marks,  on  the  left-hand  side  of  an  equals  sign.  This  line 
of  code  is  the  only  line  in  which  the  name  of  the  function  (in  quotation 
marks)  can  appear  on  the  left-hand  side  of  an  equals  sign. 

3.5.2  Referencing  Displays,  Controls,  and  Symbols  in  a  Function 

Any  HOPROC  variable  representing  a  display,  control ,  or  symbol 
can  be  referenced  in  either  of  two  ways: 

(1)  By  enclosing  the  HOPROC  variable  name  in  quotation  marks, 
or 

(2)  By  enclosing  the  HOPROC  variable  name  in  left  and  right 
carets  (<and>). 
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OPERATOR  FUNCTIONS 


DEFINED  BY  THE  NAME  OF  THE  FUNCTION  IN  QUOTATION 
MARKS  ON  THE  LEFT  SIDE  OF  AN  EQUALS  (*)  SIGN 


CAN  REFERENCE  DISPLAYS,  CONTROLS,  SYMBOLS,  OR  OTHER 
FUNCTIONS 

t  ESTIMATED  VALUES  ARE  REFERENCED  BY 
ENCLOSING  NAME  IN  QUOTATION  MARKS 

t  OTHER  PARAMETERS  ARE  REFERENCED  BY 
ENCLOSING  NAME  IN  CARETS 


Variable  names  that  are  enclosed  in  quotation  marks  reference 
the  ESTIMATED  value  of  the  display,  control,  or  symbol.  HOS  will  auto¬ 
matically  access  the  necessary  micro-models  in  order  to  either  recall  or 
absorb  the  ESTIMATED  value.  Thus,  the  two  statements  in  the  function 
TRACK-8ALL-P0SITI0N: 

EHOOKX  =  XVALUE  ('HOOK-POSITION') 

EHOOKY  =  Y VALUE  ('HOOK-POSITION') 

both  reference  the  ESTIMATED  value  of  the  HOOK-POSITION.  The  statement: 

XNEW  =  ( DHOOKX -EHOOKX )*GAIN/ 'RADAR-SCALE'  +  XVALUE 
('TRACK-BALL' ) 

references  the  ESTIMATED  values  of  both  RADAR-SCALE  and  TRACK-BALL. 

As  many  as  10  different  ESTIMATED  values  can  be  referenced  in  a 
single  function.  Each  ESTIMATED  value  can  be  referenced  as  many  times  as 
required  (or  desired)  within  the  function.  Thus,  the  two  references  to 
HOOK-POSITION  in  the  statements  above  count  as  only  a  single  reference 
towards  the  maximum  of  10  ESTIMATED  values  allowed  per  function. 

Variable  names  must  be  enclosed  in  carets  and  parentheses  when 
any  parameter  other  than  the  ESTIMATED  value  is  to  be  referenced.  For  example, 
in  the  calculation  of  the  TRACK-BALL-POSITION,  when  the  DESIRED  value  of 
the  HOOK-POSITION  is  to  be  referenced,  the  HOPROC  variable  name,  HOOK- 
POSITION,  must  be  enclosed  in  carets  and  parentheses  after  the  parameter 
name,  DESIRED,  as  in  the  statement: 

DHOOK  *  DESIRED  (<H00K-P0SITI0N>) 


3.5.3  (A)  Referencing  a  HOPROC  Variable's  Dictionary  Entry  Number 

In  certain  cases,  it  is  necessary  to  refer  in  a  function  to  the 
dictionary  entry  number  assigned  by  HOS  to  a  HOPROC  variable.*  The  dictionary 
entry  number  can  be  referenced  by  simply  enclosing  the  HOPROC  variable  name 
in  carets.  One  must,  however,  be  careful  when  referencing  certain  types  of 
HOPROC  variables  by  their  dictionary  entry  numbers  and,  in  particular,  when 
referencing  grouped  devices  through  their  dictionary  entry  number.  When 
referencing  a  display,  control,  or  symbol  group,  subroutine  REF  must  be 
called  to  replace  the  dictionary  entry  number  of  the  subgroup  with  the 
dictionary  entry  number  of  the  designated  subgroup  element  before  the 
dictionary  entry  number  is  used.  For  example,  if' we  wanted  to  refer  to  the 
dictionary  entry  number  of  the  subgroup  element  selected  by  the  IF  ANY  state¬ 
ment: 


IF  ANY  RADAR-CONTACT-STATUS  IS  NOT  ENTERED  THEN... 

the  following  statements  would  be  used: 

ID  -  <RADAR-CQNTACT-STATUS> 

CALL  REF  (ID) 

3.5.4  (A)  The  TRACK-BALL -POSITION  Function 

The  TRACK-BALL-POSITION  function,  shown  in  Figure  36,  computes 
the  position  to  which  the  operator  is  to  move  the  TRACK-BALL  based  upon  the 
OESIRED  and  ESTIMATED  values  of  the  HOOK-POSITION,  the  current  ESTIMATED 
value  of  the  TRACK-BALL,  and  certain  of  the  equipment  characteristics  — 
specifically  the  GAIN  factor  relating  movement  of  the  TRACK-BALL  to  movement 
of  the  HOCK,  and  the  current  RADAR-SCALE.  In  order  to  compute  the  position 


•Knowing  the  dictionary  entry  number  enables  the  analyst  to  refer  to 
certain  data  that  HOS  maintains  on  the  variable  that  does  not  correspond  to 
any  of  the  standard  parameters.  These  data  include  X,  Y,  and  Z  locations  of 
the  variable,  the  time  it  was  estimated,  etc. 
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to  which  the  TRACK-BALL  is  to  be  moved,  the  DESIRED  value  of  the  HOOK- 
POSITION  is  first  obtained  and  stored  as  the  FORTRAN  variable  DHOOK  by 
the  statement: 

DHOOK  =  DESIRED  (<H00K-P0SITI0N>) 

This  positional  value  is  then  decomposed  into  its  X  and  Y  components  and 
stored  as  the  FORTRAN  variables  0H00KX  and  DHOOKY  by  the  statements:* 

DHOOKX  =  XVALUE  (DHOOK) 

DHOOKY  ■  XVALUE  (DHOOK) 

Similarly,  the  X  and  Y  components  of  the  ESTIMATED  value  of  the  HOOK- 
POSITION  are  stored  as  the  FORTRAN  variables  EHOOKX  and  EHOOKY  by  the 
statements: 

EHOOKX  =  XVALUE  ('HOOK-POSITION') 

EHOOKY  *  YVALUE  ('HOOK-POSITION') 

The  new  desired  value  for  the  TRACK-BALL  can  then  be  computed 
by  taking  the  differences  between  the  respective  DESIRED  and  ESTIMATED 
components,  multiplying  by  the  system  gain  factor  and  adding  the  resultant 
values  to  the  current  TRACK-BALL  position.  These  calculations  are  performed 
by  the  two  statements: 

XNEW  =  (DHOOKX-EHOOKX )*GAIN  +  XVALUE  ('TRACK-BALL') 

YNEW  =  (DHOOKY -EHOOKY )*GAIN  +  YVALUE  ('TRACK-BALL') 

♦XVALUE  and  YVALUE  are  FORTRAN  functions  that  are  used  in  HOS  to  obtain 
the  X  and  Y  components  of  a  positional  quantity. 


The  X  and  Y  components  of  the  new  TRACK-BALL  position,  XNEW  and  YNEW,  are 
then  stored  as  the  values  of  TRACK-BALL -POSITION  by  the  statement:* 

'TRACK-BALL-POSITION'  »  PACKXY  (XNEW, YNEW) 

The  system  gain  factor,  GAIN,  is  a  function  of  an  input  gain 
factor  associated  with  an  initial  RADAR-SCALE,  and  the  current  RADAR-SCALE. 
The  input  gain  factor  must  be  divided  by  the  current  RADAR-SCALE  in  order 
to  ensure  that  the  HOOK  will  move  the  same  physical  distance  on  the  screen 
for  two  equal  movements  of  the  TRACK-BALL,  irrespective  of  the  current 
RAOAR-SCALE. 

The  system  gain  factor  is  obtained  from  input  information 
supplied  to  HOS  about  the  TRACK-BALL  by  the  statements: 

IM  «  MODEL  (<TRACK-BALL>) 

GAIN  »  PARA  (IM, 9) /’RADAR-SCALE’ 

These  statements  reference  data  that  is  supplied  to  HOS  at  execution  time  — 
the  "model"  number  associated  with  the  TRACK-BALL,  and  one  of  the  system 
parameters  (the  Input  gain  factor)  associated  with  that  model.  These  data 
will  be  discussed  in  more  detail  when  we  describe  the  inputs  to  the  HOS 
simulation. 

3.5.5  (A)  Referencing  Other  Operator  Functions 

An  operator  function  can  reference  another  operator  function  using 
the  same  conventions  described  in  Section  3.5.2  for  displays,  controls,  and 
symbols.  Care  must  be  exercised,  though,  when  a  function  is  recursive  — 
i.e.,  when  the  function  references  a  second  function  which  in  turn  references 

♦The  function  PACKXY  combines  the  X  and  Y  components  into  a  single 
value  for  storage  purposes. 


the  first.  Recursive  relationships  between  functions  are  permitted  as  long 
as  parameters  other  than  ESTIMATED  values  are  being  referenced.  Functions 
that  contain  recursive  relationships  involving  ESTIMATED  values  (i.e.,  the 
names  of  the  functions  are  in  quotation  marks)  are  noz  permitted. 


There  are  several  other  restrictions  relating  to  the  referencing 
of  one  function  from  another.  These  restrictions  are: 


(1)  An  operator  function  cannot  reference  another  function  in 
such  a  way  that  the  name  of  the  second  function  appears  in 
quotation  marks  on  the  left  side  of  an  equals  sign.  This 
restriction  exists  because  the  occurrence  of  a  function 
name  in  quotation  marks  on  the  left  side  of  an  equals  sign 
signals  the  end  of  a  function  definition. 

(2)  An  operator  function  cannot  reference  itself  by  using  the 
name  of  the  function  in  quotation  marks  in  the  function 
definition  —  this  would  be  a  recursive  relationship.  It 
can,  however,  reference  itself  through  the  use  of  the 
caret  notation. 


3.5.6  (A)  Introductory  Statements  in  the  Operator  Functions  Section 
The  operator  functions  section  is  introduced  by  an  OPERATOR 
FUNCTIONS  statement.  This  statement  is  followed  by  any  non-executable 
FORTRAN  statements  (COMMON,  DIMENSION,  EQUIVALENCE,  or  DATA  statements) 
needed  by  any  of  the  functions  in  the  section.  The  first  two  executable 
statements  after  the  non-executable  statements  must  be: 


GO  TO  1000 
9000  CONTINUE 


3.5.7  (A)  Other  Constraints  on  the  Operator  Functions 

All  the  rules  of  standard  FORTRAN  apply  to  the  OPERATOR  FUNCTIONS 
section.  Several  conventions  should,  however,  be  observed  when  coding  the 
OPERATOR  FUNCTIONS: 
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(1)  Statement  numbers  between  9000  and  10000  inclusive  should 
not  be  used  in  any  OPERATOR  FUNCTION. 

(2)  FORMAT  statements  should  use  either  the  H  convention  for 

Hollerith  fields  or  the  CDC  6600-specific  Hollerith 
delimiters  *...*  or  The  quotation  mark  Hollerith 

delimiter,  which  is  standard  on  most  FORTRAN  systems, 

should  not  be  used  since  quotation  marks  are  used  to  delimit 
HOPROC  variables. 

(3)  Though  it  is  not  strictly  necessary,  each  function  should  be 
self-contained.  That  is,  a  function  should  not  contain  a 

GO  TO  statement  that  transfers  control  to  a  statement  in 
another  function. 

(4)  The  preferred  logical  unit  for  inputting  data  (in  a  READ 
statement)  is  logical  unit  7.  Logical  unit  5  may  also  be 
used  (with  caution),  but  this  practice  is  not  recomnended. 
The  preferred  logical  unit  for  outputting  data  (via  a  WRITE 
statement)  is  logical  unit  6.  The  following  logical  units 
should  not  be  used  for  any  purpose:  8,9,10,11,12,13,14. 
Other  logical  units  may  be  referenced  if  the  PROGRAM  card 

In  HOS  Is  changed  to  acconmodate  these  logical  unit  numbers. 

(5)  Although  it  is  possible  to  reference  the  ACTUAL  values  of 
displays,  controls,  and  symbols  in  operator  functions,  this 
is  not  a  recommended  practice.  ACTUAL  values  are  the  pre¬ 
cise  hardware  values  of  the  displays,  controls,  and  symbols. 
This  information  is  presumably  only  accessible  to  the 
operator  through  the  information  absorption  and  recall 
processes.  Accessing  the  ACTUAL  values  through  the  func¬ 
tions  by-passes  these  processes. 


3.6  HAROWARE  PROCEDURES 

The  basic  structure  of  the  hardware  procedures  section  is  identical 
to  that  of  the  operator  procedures  —  the  section  begins  with  the  statement 
HARDWARE  PROCEDURES,  followed  by  the  definitions  of  the  procedures  themselves. 
Each  procedure  begins  with  a  DEFINE  statement  and  continues  until  the  next 
DEFINE  statement.  A  major  difference  between  the  two  procedures  sections, 
however,  is  in  the  nature  of  the  procedures  themselves.  In  the  operator 
procedures  section  there  are  four  special  types  of  procedures  —  ENABLE 
procedures,  ADJUST  procedures,  DISABLE  procedures,  and  MONITOR  procedures. 

In  the  hardware  section  there  is  only  one  special  type  of  procedure  — 

SIMULATE  procedures. 
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SIMULATE  PROCEDURES 


DESCRIBES  THE  EFFECTS  OF  A  SPECIFIC  CONTROL  MANIPULA¬ 
TION  ON  OTHER  DISPLAYS,  CONTROLS,  AND  SYMBOLS. 


CONTROLS  SHOULD  HAVE  SIMULATE  PROCEDRUES . 

DISPLAYS  AND  SYMBOLS  CANNOT  HAVE  SIMULATE  PROCEDURES 

CAN  HAVE  START,  MIDDLE  AND  END  ACTIONS. 
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DEFINE  THE  PROCEDURE  TO  SIMULATE  LOAO. 

STARTs  IF  the  RAOAR-OISPLAY  IS  OFF  THEN 

change  loao  to  antenna; 
change  Raoar-oisplay  to  on; 
DETERMINE  TARGET-MATRIX? 

DETERMINE  HOOK-LIMITS; 

COMPUTE  raoar-s*eep; 

END. 

CHANGE  RAOAR-OISPLAY  TO  OFF. 

Change  load  to  oummy. 

change  RAOAR-OISPLAY  to  inactive. 

CHANGE  EVERY  RAOAR-CONTACT  TO  INACTIVE. 


OEFINE  THE  PROCEDURE  TO  SIMULATE  THE  TRACK-GALL. 
MIDENO:  CHANGE  THE  TRaCK-GALL  TO  THE  NEM-QALL-POSITION. 

ENOS  CHANGE  THE  RATE  OF  THE  TRACK -GALL  TO  0.0  INCHES. 

ENO. 


start: 


DEFINE  The  PROCEDURE  TO  SIMULATE  HOOK-VERlFY. 
DETERMINE  The  HOOKED-POSITION. 

ENO. 


OEFINE  The  PROCEDURE  TO  SIMULATE  RAOAfl-MOOE. 
Enter-paoar-contact 

USING  A  NAMED-CONTROL. 

START:  PROCEED  TO  THE  NAMEO-CONTROL. 

RAOAR-MOOE :  CHANGE  ENTER-PAOAR-CONTACT  TO  ACTIVE. 

End. 

ENTER-PAOAR-CONTACT;  change  THE  HOOKED-SYMBOL  TO  ENTERED. 


MS  NON-FATAL  ERROR  8<*  IN  SUGROUTINE  NEVORD 
SSS  HOPROC  LA8EL  TRUNCATED  TO  10  CHARACTERS 


CHANGE  HOOK-VERIFY  TO  INACTIVE. 


Figuri  37.  Hardware  procadure*  for  dw  radar  plotting  simulation. 
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3.6.1  SIMULATE  Procedures 

SIMULATE  procedures,  like  ENABLE,  ADJUST,  DISABLE,  and  MONITOR 
procedures,  are  associated  with  specific  devices.  A  SIMULATE  procedure 
describes  the  effects  that  a  specific  control  manipulation  will  have  on 
other  displays,  controls,  and  symbols  in  the  crewstation.  For  example, 
when  the  SS-3  operator  turns  the  LOAD  switch  to  ANTENNA,  various  symbols 
are  displayed  on  the  RADAR -DISPLAY.  The  procedure  to  SIMULATE  LOAD  des¬ 
cribes  what  happens  when  the  LOAD  switch  is  changed  to  ANTENNA  —  i.e. , 
the  RADAR-DISPLAY  is  turned  ON  and  the  RADAR-CONTACT  symbols  are  activated, 
enabling  them  to  be  read  by  the  operator.  Every  control  used  in  the  simula¬ 
tion  should  have  an  associated  simulate  procedure  (though  this  is  not 
absolutely  necessary).  Displays  and  symbols  do  not  have  simulate  procedures. 

Simulate  procedures  are  structured  to  accommodate  the  fact  that 
some  control  manipulations  may  require  a  considerable  length  of  time  and 
that  some  hardware  activities  may  occur  at  the  beginning  of  the  manipulation, 
others  in  the  middle,  and  still  others  at  the  end.  Sections  of  a  simulate 
procedure  can  be  labeled  to  indicate  events  that  occur  at  the  beginning  of 
the  manipulation;  other  sections  can  be  labeled  to  indicate  events  applic¬ 
able  in  the  middle  of  a  manipulation,  and  still  other  events  can  be  labeled 
as  occurring  at  the  end  of  the  manipulation.  When  the  manipulation  begins, 
only  the  "start"  actions  will  be  executed.  During  the  manipulation,  only 
the  "middle"  actions  will  be  executed,  and  at  the  end  of  the  manipulation, 
only  the  "end"  actions  will  be  executed. 

The  simulate  procedures  for  the  radar  plotting  problem  are  shown 
in  Figure  37.  Three  of  the  simulate  procedures  in  Figure  37,  SIMULATE  H00K- 
VERIFY,  SIMULATE  LOAD,  and  SIMULATE  RADAR-MODE,  use  only  the  START  label. 

The  fourth  SIMULATE  procedure,  SIMULATE  TRACK-BALL,  uses  the  MIDDLE*  and  END 
labels. 


*The  label  MIDENO  indicates  actions  to  be  performed  both  in  the  middle 
of  a  manipulation  and  at  the  end  of  the  manipulation. 
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3.6.2  (A)  Regular  Hardware  Procedures 

There  are  also  "regular1*  hardware  procedures  that  are  structurally 
identical  to  regular  operator  procedures.  Any  SIMULATE  procedure  can  invoke 
a  regular  hardware  procedure  which,  in  turn,  can  invoke  still  other  regular 
hardware  procedures.  Regular  hardware  procedures,  like  operator  procedures, 
but  unlike  SIMULATE  procedures,  do  not  have  START,  MIDDLE,  and  END  sections. 
Typically,  regular  hardware  procedures  are  executed  immediately  and  com¬ 
pletely.  Hardware  procedures  can,  however,  be  put  on  an  active  procedures 
list  similar  to  the  active  procedure  list  for  operator  procedures.  The 
active  hardware  procedures  list  differs  from  the  active  operator  procedures 
l_ist  in  that  active  hardware  procedures  are  generally  executed  every  time 
the  hardware  is  updated.  This  feature  is  useful  for  procedures  that,  for 
example,  update  the  locations  of  the  symbols  on  a  display  screen  —  every 
time  the  hardware  is  updated,  the  locations  of  all  the  symbols  on  the  screen 
will  be  updated  to  conform  to  their  new  real-world  locations.  The  analyst 
can  also  specify  a  frequency  with  which  a  hardware  procedure  is  to  be 
executed  —  for  example,  a  hardware  procedure  may  only  have  to  be  executed 
once  every  five  seconds.  Specifying  an  update  frequency  can  help  to  cut 
down  on  the  amount  of  computer  time  required  for  the  simulation,  by  eliminat¬ 
ing  unnecessary  hardware  procedure  executions. 

3.6.3  The  Radar  Plotting  Hardware  Procedures 

The  radar  plotting  hardware  procedures  will  be  discussed  below 
in  the  order  in  which  these  procedures  are  executed  as  determined  by  the 
actions  taken  by  the  operator.  In  these  discussions,  we  will  only  indicate 

(1)  The  ways  in  which  the  hardware  procedures  (and  functions) 
differ  from  the  operator  procedures  (and  functions),  and 

(2)  Any  new  constructs  that  have  not  already  been  discussed 
in  the  preceding  sections. 

3. 5. A  SIMULATE  Procedures  for  Discrete  Controls 

The  first  control  action  that  the  operator  performs  in  the  HOS 
radar  plotting  simulation  is  to  switch  the  LOAD  switch  to  the  ANTENNA 


position.  When  this  occurs,  three  hardware  functions  occur  --  the  actual 
value  of  the  LOAD  switch  is  changed  to  ANTENNA,  the  radar-display  is  turned 
on,  and  the  locations  of  the  targets  in  the  real-world  are  displayed  on  the 
radar  screen.  These  functions  are  performed  by  the  SIMULATE  L0An  procedure. 

The  first  statement  in  this  procedure 

IF  THE  RADAR-OISPLAY  IS  OFF  THEN... 

distinguishes  between  turning  the  LOAD  switch  from  DUMMY  to  ANTENNA  and 
from  ANTENNA  to  DUMMY.  When  the  LOAD  switch  is  in  the  DUMMY  position,  as 
it  will  be  at  the  beginning  of  the  simulation,  the  RADAR-DISPLAY  will  be 
OFF.  Changing  the  LOAD  switch  to  the  ANTENNA  position  turns  the  RADAR- 
DISPLAY  ON.  Therefore,  if  the  RADAR-DISPLAY  is  OFF  at  the  start  of  the 
manipulation,  then  the  first  actions  to  be  taken  are  to: 

CHANGE  RADAR-DISPLAY  TO  ON; 

CHANGE  LOAD  TO  ANTENNA; 

These  two  statements  are  easily  recognizable  as  ALTER  statements. 
However,  they  differ  in  one  important  respect  from  the  ALTER  statements  in 
the  operator  procedures  --  whereas  ALTER  statements  in  the  operator  pro¬ 
cedures  section  implicitly  referred  to  the  DESIRED  value  of  a  device,  ALTER 
statements  in  the  hardware  procedures  section  implicitly  refer  to  the  ACTUAL 
value  of  the  device.  Thus,  these  statements  change  the  ACTUAL  value  of 
the  RADAR-DISPLAY  to  ON  and  the  ACTUAL  value  of  the  LOAD  switch  to  ANTENNA. 

3.6.5  Hardware  Functions 

The  next  three  statements: 

DETERMINE  TARGET-MATRIX; 


1 


i 


i 
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TAR(jFT-“ATOtx 

REAO  (7.900)  NTGTS 
900  FORMAT  { r  2 ) 

RFAO  (7.901)  (XT(IO)  .77(10)  .HTtl'J)  .RT(IO)  *I0*1.nTGTS) 

9QJ  FORMAT  ( AF  S . 0 ) 

• T aRGFT-maTR I  X  *  aO 
-*f)OKXaX\/ALUF  (  •wOOK-PQS  [T ION  *  ) 

HOOKYaWALue  (  'i-OOK -POSITION*  ) 

HOOKLa"?AOAR-SCALF*»*MOnK-«AOTUS  * /16 

UPPER  (  <WOOK-POSITION»)  aPACKXY  (-.OOXX^OOK  u  .HOOKY -rtOOKL) 

LOWER ( <HOOK-POSITTON>) aBACXXY (HOOKX-hOOKL.HOOKY-MUOKL) 
•mOOk-lImITS*  3M00KL 
no  300  Ial.NTGTS 

XT  ( I )  a  xT  ( I )  .  RT(n*«;iN(MT(I)*->I/ia0.0)*(STIME-ITlYE)/3o00.0 
YT  <  I )  aYT(I)  ♦  »T(I)*Cf!S(MT(I>*RI/If>0.)*(STlM£-Tri,-£)/3600.0 
CALL  Symp^tni  <Oa0AP-CENTFw>.<Ra0a'--C0nTaCT-STaTUS>*I  . 

•  <R aOAP-COnT act-STaTUS>*I* • RaOaR-SCalE  *  *  1 ♦ xT ( I ) • r T ( i > ) 

STATE ( <paoar-contact-status>*t ) si 

STATE ( <RAOAP-CDNTACT-PO« I TI0N>*I ) =L 
300  CONTINUF 

TTIMFaCTlMP 

• R AQAR— SWPPP • a i 


Figura  38.  Hardtaara  functions  for  radar  plotting  simulation. 
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DETERMINE  HOOK-LIMITS; 
COMPUTE  RADAR-SWEEP; 


are  easily  recognizable  as  COMPUTE  statements.  These  statements  initiate 
the  execution  of  the  three  hardware  functions  shown  in  Figure  38.  The 
first  function,  TARGET -MATRIX,  reads  in  a  set  of  data  cards  containing  the 
coordinates  of  the  targets  to  be  plotted,  their  speeds  and  headings.  This 
function  illustrates  how  an  operator  function  can  be  used  to  read  in  data 
at  execution  time.  This  capability  enables  the  HOS  hardware  and  operator 
procedures  to  be  developed  independently  from  the  "real-world  data"  that 
"will  obtain  at  the  time  the  simulation  is  run.  New  real-world  situations 
can  then  be  created  and  run  through  the  model  without  having  to  rewrite 
and  procedures  or  recompile  any  program  comoonents. 

The  second  function,  HOOK-LIMITS,  establishes  limiting  values  for 
the  HOOK-POSITION.  The  upper  limit,  UPPER  (<HOOK-POSITION>)  is  obtained 
by  taking  the  distance  that  converts  the  HOOK-RADIUS  (given  in  inches)  to 
the  value  (in  miles)  represented  by  the  HOOK-RADIUS  to  the  X  and  Y  com¬ 
ponents  of  the  current  value  of  the  HOOK-POSITION.  The  lower  limit,  LOWER 
(<H00K-P0SITI0N>)  is  obtained  by  subtracting  the  same  amount  from  the  cur¬ 
rent  HOOK-POSITION.  The  upper  and  lower  limits  thus  define  a  square  (rather 
than  the  circle  that  is  the  actual  shape  of  the  HOOK)  within  which  the 
hook  must  be  in  order  to  satisfy  an  IF...  OK  or  IF...  WITHIN  LIMITS  test. 

The  third  function,  RADAR-SWEEP,  places  the  targets  that  were  read 
in  by  the  TARGET -MATRIX  function  onto  the  screen  as  active  RADAR-CONTACTS. 
This  function  uses  the  subroutine  SYMPSTN*  to  place  the  symbols  on  the 
screen  at  their  current  real-world  locations.  The  statements: 

STATE  ( <RADAR-CONTACT -STATUS>  +  I)  =  1 

STATE  (<RADAR-CONTACT-PGSITION>  +  I)  =  1 


♦Described  in  more  detail  in  the  HOS  Users'  Guide  and  on  the  HOS 
Reference  Card. 
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sat  the  STATE  of  the  i  £h  RADAR -CONTACT' s  characteristics,  STATUS  and  POSITION, 
to  1  (ACTIVE),  thereby  enabling  the  operator  to  read  these  symbol  characteristics. 

3.5.6  (A)  Altering  the  STATE  of  a  Display,  Control,  or  Symbol 

If  the  operator  had  changed  the  LOAD  switch  from  ANTENNA  to  DUMMY, 
the  statements: 

CHANGE  RADAR-0 ISPUY  TO  OFF. 

CHANGE  LOAD  TO  DUMMY. 

CHANGE  RAOAR-OISPIAY  TO  INACTIVE. 

CHANGE  EVERY  RADAR-CONTACT  TO  INACTIVE. 

would  have  been  executed.  The  first  two  ALTER  statements  are  self-explanatory. 
The  thira  statement  changes  the  STATE  parameter  associated  with  the  RADAR- 
OISPLAY  to  INACTIVE.*  This  means  that  the  operator  will  once  again  have  to 
execute  the  ENABLE  procedure  for  RADAR -01 SPLAY  before  he  will  be  able  to 
'•ead  any  information  from  the  RADAR-DISPLAY.  The  fourth  statement  changes 
the  STATE  parameter  for  every  RADAR-CONTACT  on  the  RADAR-OISPLAY  to  INACTIVE. 

All  the  characteristics  of  every  RADAR-CONTACT,  i.e. ,  both  the  STATUS  and 
POSITION  characteristics,  will  be  made  INACTIVE.  Consequently,  the  operator 
will  not  be  able  to  read  any  of  the  RADAR-CONTACT-STATUS  or  RADAR-CONTACT - 
POSITION  values  without  enabling  the  RADAR -01 SPLAY.** 

3.6.7  SIMULATE  Procedures  for  Continuous  Controls 

The  next  action  that  the  operator  performs  is  the  manipulation  of 
the  TRACK-BALL.  The  hardware  consequences  of  a  TRACK-BALL  manipulation  are 
described  by  the  PROCEDURE  TO  SIMULATE  THE  TRACK-BALL  (Figure  39).  Since  the 


*The  parameter  STATE  is  understood  implicitly  because  of  the  use  of 
the  keyword  INACTIVE. 

**The  RADAR-CONTACT  symbols  have  to  be  inactivated  independently  from 
the  RAOAR-OISPLAY  because  of  the  fact  the  HOS  does  not  recognize  that  the 
RAOAR-CONTACTs  are  on  the  RAOAR-OISPLAY. 
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DEFINE  THE  PROCEDURE  TO  SIMULATE  ThE  TRACK-BALL. 
MIDFMO:  CHANGE  The  T°ACK-8ALL  TO  THE  NE*-BALL“POSITION. 

ENO:  Change  ThE  PATE  OF  THE  TRaCk-haLL  TO  0.0  INCHES. 

ENO. 


Figure  39.  Procedure  to  simulate  the  TRACK-BALL. 
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XPALLaXVALUE  (  *  trackball  '  > 

YBAtL*yVALUE ( ’TRACK -SAUL  '  ) 

I 08 ALL a < TRACK ALL > 

RXaXVALUC  (RATE  (  IO0ALU  ) 

RYSYVALUE (RATE < I 08 ALL ) ) 

T  3  STTMe-riMC( IORALL) 

XN£WsXR4LL*T*RX 
YN£WaYqALL*T»RY 
I M  a  MfinfL  (  I08ALL) 

GAIN  a  PARA ( rM»R) 

XHOOKaxvALUE ( ’hOOK-PORITION* ) *T*^x*»RaoaR-SCALE’/GAI y 
YMOOKaYVALUEt • hOOk-POR I T ION • > *T*R Y • * R AO AR-SCALE ' /GA I N 
CALL  S^MPSTN  (  <RAOaP-CE'JTER>  .  <hOO*>  *  <MDOK-POS IT ION> » 
•pahaR-SCALE'  ♦  I  .Xwr)OK»YHOOK) 

*  N£V<-a  ALL-OOSI  TION*  aPACK  XY  (  XNEVX  .  YNg* ) 


Figure  40.  T7w  NEW-8ALL-POS1T10N  hardware  function. 
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TRACK-BALL  is  a  continuous  (positional)  device,  there  are  hardware  events 
that  occur  throughout  the  manipulation  --  specifically  the  ACTUAL  value  of 
the  TRACK-BALL  will  change  throughout  the  manipulation  and  the  ACTUAL  value 
of  the  HOOK-POSITION  will  change  concurrently  to  conform  to  the  new  track¬ 
ball  position.  The  hardware  function,  NEW-BALL-POSITION  (Figure  40  ), 
computes  the  new  positions  for  both  the  TRACK-BALL  and  the  HOOK.  The 
statement: 


CHANGE  THE  TRACK-BALL  TO  THE  NEW-BALL-POSITION. 

sets  the  ACTUAL  value  of  the  TRACK-BALL  to  the  result  of  the  NEW-BALL- 
POSITION  calculation  (the  new  HOOK-POSITION  is  set  internally  within  the 
function) . 

3.6.8  (A)  The  RATE  and  TIME  Parameters 

The  NEW-8ALL-P0SITI0N  function  (Figure  40  )  references  two  param¬ 
eters  associated  with  the  TRACK-BALL  —  its  RATE  and  its  TIME.  When  the 
control  manipulation  is  begun,  HOS  will  automatically  set  the  RATE  of  the 
TRACK-BALL  to  a  value  dependent  on 

(1)  The  current  position  of  the  TRACK-BALL, 

(2)  Where  the  operator  will  be  moving  the  TRACK-BALL  to,  and 

(3)  The  amount  of  time  the  manipulation  will  take. 

The  RATE  will  be  assumed  to  be  constant  throughout  the  manipulation,  after 
which  it  will  be  set  to  zero  by  the  statement: 

CHANGE  THE  RATE  OF  THE  TRACK-BALL  TO  0,0  INCHES. 

Throughout  the  manipulation,  the  RATE  parameter  is  available  for  use  in 
calculations  such  as  the  calculation  of  the  new  HOOK-POSITION  in  NEW-BALL- 
POSITION. 
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DEFINE  THE  PROCEDURE  TO  SIMULATE  HOO*-VERlFY. 
START:  DETERMINE  Th£  mOOkED-POSITION. 

EnO. 

DEFINE  THE  PROCEDURE  TO  SIMULATE  RaOAP-moOE. 
ENT£P-PaOAP-COnTACT 
USING  A  NAMED-CONTROL. 

STaoT:  PROCEED  TO  THE  NAMED-CONTROL . 

RAOAP--OOE:  CHANGE  £NT£R-RaOAR-CONTACT  TO  ACTIVE. 

ENO. 

ENTER-RAOAP-CONTACT :  change  Th£  HOOKED-SYMBOL  TO  ENTERED. 

Change  hOOk-vEPIFY  To  Inactive. 

ENO. 


Figure  41.  Th*  nmuira  procadum  for  HOOK- VERIFY,  RADAR  MODE 
and  ENTER-RADAfl-CONTACT. 


The  other  parameter  referenced  in  the  NEV1-BALL-P0SITI0N  calculation 
is  the  TIME  parameter.  This  parameter  represents  the  last  time  (in  seconds) 
that  the  control  was  updated.  Therefore,  by  subtracting  this  time  from  the 
current  simulation  time,  STIME,  and  multiplying  by  the  rates  of  movement,  the 
change  in  the  TRACK-BALL'S  position  (and  in  the  HOOK-POSITION)  can  be  calculated. 

3.6.9  SIMULATE  Procedures  for  Momentary  Controls 

After  having  manipulated  the  TRACK-BALL  so  that  the  HOOK  is  in 
the  correct  position,  the  operator  depresses  the  HOOK-VERIFY  pushbutton. 

The  SIMULATE  procedure  that  is  invoked  when  this  control  manipulation  is 
-performed  is  shown  in  Figure  41  .  This  procedure  simply  calls  the  HOOKED- 
POSITION  function,  shown  in  Figure  42  ,  which  determines  which  symbol  has 
been  hooked. 

3.6.10  Multiple  Titles  in  a  Procedure  Definition 

The  next  two  actions  that  the  operator  takes  are  to  depress  the 
RADAR-MODE  and  the  ENTER-RADAR-CONTACT  switches.  Since  both  of  these  switches 
are  associated  with  the  radar-matrix  functions  on  the  keyset  tray,  a  single 
SIMULATE  procedure  has  been  defined  for  both  controls.  This  is  done  by 
simply  listing  the  names  of  both  controls  in  the  DEFINE  statement.  As  many 
controls  as  desired  can  be  defined  by  a  single  SIMULATE  procedure.*  However, 
there  is  a  practical  limitation  that  results  from  the  fact  that,  within  the 
procedure,  the  actions  that  are  to  occur  as  a  result  of  having  manipulated 
one  control  as  opposed  to  another  must  be  distinguishable.  Therefore,  only 
controls  that  "belong"  together  and/or  have  several  functions  in  common 
should  be  grouped  together  in  a  single  SIMULATE  procedure. 


♦This  is  also  true  for  ENABLE,  ADJUST,  DISABLE,  and  MONITOR  procedures. 
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inHOOK3<HOO*-»OStTIO*> 

OmIN*«mOOK-o aqihp  • 

101  s  o 
T02  =  n 

I  3<h00kFD-SY*«h0L  > 

CALL 

rp  (I.OT.O)  aCTUAL(I)  =  <QN> 
r^TAOT=^^o<;.  i 

200  ip  ( israJT.GT..Ntn<;vu,  r-n  to  220 

call  svusch t rsTitf r . rosrv, iopos. rsreyj 
IF  (inoos.PO.IOHQOK)  Gq  TO  210 

IP  <PTATE< ns**! .MP.l.no.ACTUALf IOSYM) ,£Q.<OKF>)  u 0  TO  210 

snisr  s  oist ( toiM< iohoco  ♦  yoi*<io«ooio  *zoim<io»ooio  ♦ 

.  X0IM(  IOPOS1  ♦  Y0I«(  I'JPOS)  .  70IVMI0P0S)) 

ip  csoist.gt.omih)  r, o  re  210 

0MIN3SOIST 

roi  »  iosy« 

T02  3  rnpns 

210  rPTAPT  s  rnPO?  .  1 

30  to  poo 

220  IP  (ini.eo.Ol  00  TO  230 

actual ( roi) 3<moo*po> 

NS£TI  (<-tOO«EQ-SY"MOL>>  *  IDl 
SO  I  ST  3  ACTUAL (102) 

GO  TO  ?<-0 

230  NScTI ( <wOO*EO-Sym«ol>>  3  u 
SOIST  s  'K30K-O0SITI0M' 

?<*0  COMTINUP 

•  wOO*fPO-POSITTON»  s  SniST 


Rguro  42.  Th*  HOOKED-POSITION  hirdvMrt  function. 


3.6.11  Arguments 

The  argument  NAMED-CONTROL  is  used  to  distinguish  which  control 
is  being  used  when  the  SIMULATE  procedure  is  executed.  Arguments  are  "dummy" 
HOPROC  variable  names  that  can  be  used  to  serve  a  variety  of  functions. 
Typically,  an  argument  is  used  in  place  of  an  actual  HOPROC  variable  in  a 
statement  in  which  the  name  of  the  referenced  HOPROC  variable  is  unknown 
at  the  time  the  HOPROC  code  is  being  written.  For  example,  in  the  statement: 

DEFINE  THE  PROCEDURE  TO  SIMULATE  RADAR-MODE, 

ENTER-RADAR-CONTACT  USING  NAMED-CONTROL. 

the  argument  NAMED-CONTROL  is  mentioned  in  a  USING  clause.  When  either  the 
RADAR-MOOE  or  ENTER-RADAR-CONTACT  control  is  used  in  the  simulation,  NAMED- 
CONTROL  will  be  set  so  that  it  references  the  control.  No  matter  which 
control  is  being  used,  the  control  can  therefore  be  referenced  in  the 
SIMULATE  procedure  (or  elsewhere)  by  referring  to  NAMED-CONTROL  rather  than 
by  referring  to  the  actual  name  of  the  control. 

Some  of  the  other  ways  in  which  arguments  can  be  used  will  be 
described  below. 

3.6.12  (A)  Arguments  and  PERFORM  (START)  Statements 

Arguments  can  be  used  in  PERFORM  (or  START)  statements  to  pass 
values  from  one  procedure  to  another.  For  example,  the  statement: 

INCREMENT-SIMULATION-TIME  USING  NORMAL  180.  (+-)  10. 

will  set  the  arguments  DISTRIBUTION-TYPE,  MEAN,  and  STANDARD-DEVIATION  in  the 
procedure  INCREMENT-SIMULATION-TIME,  to  the  values  NORMAL,  189.,  and  10., 
respectively,*  as  a  consequence  of  the  DEFINE  statement: 


♦The  +-  in  parentheses  is  an  example  of  a  HOPROC  acrment.  Words 
enclosed  in  parentheses  are  ignored  by  the  HOPROC  processing  program  HAL. 


ARGUMENTS 

DUMMY  HOPROC  VARIABLES 

CAN  BE  USED  IN: 

•  USING  CLAUSES 

•  GO  TO  STATEMENTS 

t  IN  OTHER  PROCEDURAL  STATEMENTS 


DEFINE  INCREMENT-SIMULATION-TIME  USING  DISTRIBUTION-TYPE, 
MEAN,  STANDARD-DEVIATION. 


The  number  of  values  specified  in  the  PERFORM  (or  START)  statement  must 
agree  with  the  number  of  arguments  in  the  DEFINE  statement  for  the  pro¬ 
cedure  being  invoked  by  the  PERFORM  (or  START)  statement. 

3.6.13  Arguments  in  GO  TO  Statements 

The  first  statement  in  the  SIMULATE  procedure  for  RADAR-MODE 
and  ENTER-RADAR-CONTACT  is  a  GO  TO  statement  that  uses  the  argument  NAMED- 
CONTROL  instead  of  a  statement  label.  When  HOS  encounters  this  statement, 
it  looks  for  a  statement  label  that  is  the  same  as  the  name  of  the  control 
being  manipulated.  Since  the  SIMULATE  procedure  defines  the  hardware  actions 
for  both  RADAR-MODE  and  ENTER-RADAR-CONTACT,  there  must  be  statements  in 
the  procedure  labeled  with  the  labels  RADAR-MODE  and  ENTER-RADAR-CONTACT. 
These  statements  identify  the  sections  of  code  in  the  SIMULATE  procedure 
that  describe  the  hardware  actions  to  occur  when  the  respective  controls  are 
depressed. 

3.6.14  Arguments  in  ALTER  Statements 

The  action  that  is  taken  when  ENTER-RADAR-CONTACT  is  depressed 

is  to: 


CHANGE  HOOKED-SYMBOL  TO  ENTERED. 

The  HOPROC  variable  HOOKED-SYMBOL  is  an  argument  whose  value  is 
set  by  the  hardware  function  HOOKED-POSITION.  The  argument  indicates  which 
symbol  has  been  hooked  by  the  operator.  It  will  correspond,  in  this  case, 
to  one  of  the  elements  in  the  RADAR-CONTACT-STATUS  subgroup. 
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ARGUMENT  section 

HGOKEO-SYMQOL 

NAMED-CONTROL 


Figura  43.  Tha  ARGUMENT  SECTION  for  ttw  radar  plotting  simulation 
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3.6.15  The  ARGUMENT  SECTION 

All  the  argument  titles  used  anywhere  in  the  operator  and/or 
hardware  procedures  and/or  functions  must  be  grouped  together  in  the  title 
declarations  section.  The  list  of  arguments  must  be  introduced  by  an 
ARGUMENT  SECTION  statement.  Figure  43  shows  the  ARGUMENT  SECTION  used  in 
the  radar  plotting  simulation. 

3.7  THE  HOPROC  DATA  DECK 

The  complete  HOPROC  data  deck  for  the  radar  plotting  simulation 
is  shown  in  Figures  44  through  48  .  The  deck  consists  of  the  settings, 

_arguments,  displays,  controls,  symbols,  operator  functions,  hardware 
functions,  hardware  procedures,  and  operator  procedures  that  have  been 
described  in  the  preceding  sections.  The  first  card  in  the  data  deck  is 
an  optional  SYSTEM  card  that  is  used  to  identify  the  deck  and  to  label  the 
output  that  HOS  will  generate.  The  only  other  card(s)  that  may  be  desired 
in  the  data  deck  are  optional  cards  that  control  certain  of  the  outputs 
generated  by  the  program  (HAL)  that  process  the  HOPROC  data  deck.  The 
optional  output  controlled  by  these  cards,  the  HOS  DATA  DECK  and  the  NO 
DATA  DECK  cards,  will  be  described  in  Section  4. 
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SYSTEM  OEMO  PROGRAM  —  RADAR  PLOTTING 

SETTING  SECTION 
ANTENNA 
9LANK 
OUMMY 
ENTERED 
HOOKED 
OFF  ON 

OSTaTE  SECTION 
ARGUMENT  SECTION 


HOOKED-SYMgOL 
NAMED-CONTROL 
DISPLAY  SECTION 

RADAR-0  I  SPLAY 
RAOAR-SCALE 
RAOAR-CENTEP 
CONTROL  SECTION 
loao 

TRACK-SALL 
RAOAR-MOOE 
HOOK-VERIFY 
ENTER-RAOAfl-CONTACT 
SYMBOL  SECTION 
HOOK 

HOOK -RAO  I US 
HOOK-POSITION 
RAOAR-CONTACT  2,10 

status 

POSITIi 


SETTINGS  OFF  ON. 

SCALE  MILES 
COORDINATES  MILES 

SETTINGS  OUMMY  ANTENNA. 

COORDINATES  INCHES 

MOMENTARY 

MOMENTARY 

MOMENTARY 

SETTINGS  ON. 

SCALE  INCHES 
COORDINATES  MILES 

SETTINGS  ENTERED  BLANK  HOOKED. 
COORDINATES  MILES 


Figure  44.  Title  declarations  for  die  radar  plotting  simulation. 
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no  n  o  o  o 


OPERATOR  FUNCTIONS 
GO  TO  10000 
9000  CONTINUE 

TPACK-8ALL-POSITI0N 

OBTAIN  OESIRED  ANO  ESTIMATED  HOOK  POSITIONS 
OHOOK=OESIRED (<HOOK-POSI TI0N>) 

DHOOKXsXVALUE (OHOOK) 

OHOOKYsYVALUE (DHOOK) 

-  EHOOKXsXVALUE ( 'HOOK-POSITION' ) 

EHOOKYsYVALUE ( 'HOOK-POSITION* ) 

COMPUTE  DESIRED  TRACK  BALL  POSITION  BASED  ON  SCREEN  SCALE  FACTOR 

and  gain  factor  for  track  ball 
IMSMODEL  <<TRACK-8ALL>) 

GAIN=PARA  < IM,9) 

XNEW= ( DHOOK X-E HOOK X ) *GA I N/ • RAOAR-SCALE • *  X VALUE (• TRACK-BALL • ) 
YNEW= ( DHOOKY -SHOOK Y ) *GA I N/ • RAOAR-SCALE • -Y VALUE < 'TRACK-BALL' ) 

•  TRACK-BALL-POSIT  ION ' sPACKXY (XNE^tYNEW) 


Figure  AS.  Operator  functions  for  the  radar  plotting  simulation. 
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HAPOWAPE  FUNCTIONS 

COMMON  /TAPGETS/XT  ( 10 )  iYTUO)  .PT(lO)  iHT(IO) 

DATA  PI/3.1M592651/ 

GO  TO  10000 
9000  CONTINUE 
C 

C  TARGET-MATRIX 
C 

9EA0  (7.900)  NTGT5 

900  FORMAT  (12) 

9EA0  (7,901)  (XT(10) «YT(10) ,MT(IO) ,RT(IO) .IOal.NTGTS) 

901  FORMAT  (4FS.0) 

’TAflGET-MATRIX'sO 
hOOKX=XVALUE( 'hOOK-POSITION* ) 

HOOKYaYVALUE ( ♦ HOOK -POS I T I  ON  * ) 

H00KL*1 RAO AR— SCALE '  ♦•HOOK-PAO  I'JS  *  /16 

UPPER ( <HQOK -POS I T 1 0N> ) sP  ACXX  Y ( HOOKX*hOOKL . HOOKY -HOOKL ) 

LOWER ( <HOOK-POS IT ION> ) aP ACXXY ( HOOKX-HOOKL .HOOK Y-HGOKL ) 

• HOOK-L I M I TS • aMOOKL 
00  300  Isl .NTGTS 

XT ( I )  a  XT ( 1 )  *  PT(l)*SIN<HT(I)*PI/iaO.O)*(STIME-TTlM€)/3600.0 
-  YT(I)  a  >T(I)  *  PT( I) •COS(HT(I) *PI/ 18Q.) *(STIME-TTImE) /3600.0 
CALL  SYMPSTN ( < R AO AR— CENTER >  »<RA0Art-C0NT ACT-STATUS>* 1 » 

«  <RaOaR-CQNTACT-5TATUS>-I» 'RADAR-SCALE* *1»XT(1> » YT ( I ) ) 

STATE ( <RaOaP-COnTACT-5TaTUS>*  I ) ~ 1 

STATE  (<PAOAP-CONTACT-P(TSITION>*I)  ai 

300  CONTINUE 

TTlMEaSTIME 
' PAOaP-SWEEP  *  a 1 
X8ALL3XVALUE ( *  TRACK -BALL * ) 

Y0 ALL* Y VALUE ( • TRACK-BALL  '  > 

I 08 ALL *< TRACK -3 ALL > 

RX3XVALUE(RATE( I08ALL) ) 

PYaYVALUE (PATE  t I08ALL) ) 

T  *  STIME-TIME(108ALL> 

XNEWaXgALL*T*RX 

YN£WaYgALL*T*RY 

IM  »  M00EL(I08ALL) 

GAIN  3  PAPA ( I*,9) 

XH00K3XVALUE( 'NOOK -POSITION* ) *T*RX* »  RAOAP-SCaLE ' /GAIN 
YHQOKrYVALUE ( • MOCK-POS I T ION • ) «T*RY* ♦ RAOAP- SCALE ' /GA I N 
CALL  SYMPSTN  <  <PAOAR-CENTEH> . <HOOK > , <H00K -POSITION* . 

*  *paoap-scal£* *1 .xhook.yhook) 

• N£W-8 ALL“POS I T I ON ' aPACKXY (XNEW.YNEW) 

IOhOOK3<hOOK-POSITION> 

OMIN= • HOOK -RAO  I  US ' 

101  *  0 

ro2  *  o 

I 3<HOOK£0-SYM60L> 

CALL  P£F (  I) 

IF  (I.GT.O)  ACTUAL  ( 1  )  =  <0N> 

ISTAPT=N00S*1 

Figure  46.  Hardware  functions  for  tha  radar  plotting  simulation. 
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200  IF  ( ISTART ,  GT . NOSYM)  GO  TO  220 

CALL  SYMSCH( ISTART, IOSYM, IOPOS, ISTEP) 

IF  (IDPOS.EQ. IDHOOK)  GO  TO  210 

IF  (STATE ( IOSYM) .N£. 1. OR. ACTUALf IOSYM) .£Q.<OFF>)  GO  TO  210 
SO  1ST  =  OIST (XOIM(IOHOOK) ,YDIM( IDHOOK) ,ZDIM< IDHOOK) , 

♦  XOIM(IDPOS),  YOIM(IOPOS),  ZOIM(IDPOS)) 

IF  (SOIST.GT.OMIN)  GO  TO  210 

DMIN=SOIST 

101  =  IOSYM 

ID2  =  IOPOS 

210  ISTART  =  IOPOS  ♦  1 
GO  TO  200 

220  IF  (IDI.EQ.O)  GO  TO  230 
ACTUAL ( 101 ) =<MOOKED> 

NSET1 (<HOOKED-SYM0OL>)  =  101 
SOIST  =  ACTUAL (102) 

GO  TO  240 

230  NSET1 (<hOOKED-SYM0OL>)  =  0 
SOIST  =  'HOOK-POSITION* 

240  CONTINUE 

•HOOKED-POSITION*  =  SOIST 


Figure  46.  Hardware  functions  for  the  radar  plotting  simulation,  (cont.) 
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HARDWARE  PROCEDURES 

DEFINE  THE  PROCEDURE  TO  SIMULATE  LOAO. 

START:  IF  the  raoar-oisplay  IS  off  then 

CHANGE  LOAO  TO  ANTENNA  5 
CHANGE  RAOAR-OISPLAY  TO  QNt 
DETERMINE  target-matrix; 

DETERMINE  HOOK-LIMITS; 

compute  Raqar-sweep; 

ENO. 

CHANGE  RAOAR-OISPLAY  TO  OFF. 

CHANGE  LOAO  TO  DUMMY. 

CHANGE  RAOAR-OISPLAY  TO  INACTIVE. 

CHANGE  every  raoar-contact  TO  INACTIVE. 

DEFINE  THE  PROCEDURE  TO  SIMULATE  THE  TRACK -8 ALL. 
MIDENO:  CHANGE  THE  TRACK-0ALL  TO  THE  NE*-8ALL-P0SITI0N. 

ENO:  CHANGE  THE  PATE  OF  THE  TRaCK-8aLL  TO  0»0  INCHES. 

ENO. 

DEFINE  THE  PROCEDURE  TO  SIMULATE  HOOK-VERIFY. 

START:  DETERMINE  THE  HOOKED-POSITION. 

End. 

OEFINE  THE  PROCEDURE  TO  SIMULATE  RAOAR-MOOE * 
ENTER-RAOAR-CONTACT 
USING  A  NAM£D-CONTROL. 

START:  PROCEED  TO  THE  NAMED-CONTROL. 

RAOAR-moOE:  CHANGE  ENTER-RAOAR-CONTACT  TO  ACTIVE. 

ENO. 

ENTER-RAOAR-CONTACT:  CHANGE  THE  HOOKED-SYMfiOL  TO  ENTERED. 

CHANGE  HOOK-VERIFY  TO  INACTIVE. 

ENO. 


Figure  47.  Hardware  procedures  for  the  radar  plotting  simulation. 
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OPERATOR 


ENTER: 


CHECK: 


PROCEDURES 
DEFINE  THE  MISSION. 

perform  raoar-plot. 

ENO. 

DEFINE  THE  PROCEDURE  TO  RAOAR-PLOT. 

ENABLE  THE  RAOAR-OISPLAY. 

IF  ANY  RAOAR-CONTACT-STATUS  IS  NOT  ENTERED  THEN 

DESIGNATE  IT  AS  THE  RADAR-CONTACT  OF  INTEREST 
MOVE  THE  HOOK-POSITION  TO  THE 

radar-contact-position; 
oepress  hcok-verify; 

OEPRESS  ENTER-RADAR-CONTACT. 

IF  ANOTHER  RADAR-CONTACT-STATUS  IS  NOT  ENTERED 
THEN  GO  TO  ENTER  NOW. 

ENO. 

OEFI N£  THE  PROCEDURE  TO  ENABLE  THE  RADAR-DISPLAY. 

TURN  LOAO  TO  ANTENNA. 

ENO. 

DEFINE  THE  PROCEDURE  TO  AOJUST  THE  HOOK-POSITION. 

REAO  THE  HOOK-POSITION. 

IF  IT  IS  OK  THEN  ENO. 

DETERMINE  THE  TRACK-BALL-POSITION. 

MOVE  THE  TRACK-8ALL  TO  THE  RESULT. 

IF  THE  RATE  OF  THE  TRACK-BALL  IS  NOT  0.0  INCHES 
THEN  WAIT. 

GO  TO  CHECK  NOW. 

OEFINE  THE  PROCEDURE  TO  ENABLE  hOOk-VERIFy. 

AOJUST  THE  HOOK-POSITION. 

ENO. 

DEFINE  The  PROCEDURE  TO  ENABLE  ENTER-RADAR-CONTACT. 
DEPRESS  RADAR-mOQE. 


Figure  43.  Operator  procedures  for  the  radar  platting  simulation. 
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job,  name,  core,  time,  PK1 . 
ACCOUNT,  charge,  password. 
PACKNAM,  PN  »  PACKQQ6. 

SET,  CCEXEC/UN  -  CS0689. 
GET,  HGSEXEC/UN  3  CS0689. 
CCEXEC,  HOSEXEC,  step  1. 

CCEXEC,  HOSEXEC,  step  2. 


data  for  step  1 


data  for  step  2 


I  NAME  3  name) 
FILE  3  file 
RUN  3  run  j 


Figure  49.  Deck  Structure  for  a  HOS  Simulation 
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4.  HOW  TO  RUN  HOS 


HOS  is  a  set  of  three  major  computer  programs  linked  to  one 
another  by  the  specific  problem  description  formulated  by  the  analyst. 

The  characteristics  of  the  problem  provide  the  data  that  the  first  HOS  pro¬ 
gram,  HAL,  uses  to  generate  portions  of  the  second  and  third  computer  pro¬ 
grams,  HOS  and  HODAC.  Consequently,  there  is  a  sequence  of  steps  that  the 
user  must  follow  in  order  properly  to  get  from  one  program  to  the  next. 

At  certain  steps,  there  may  be  data  that  must  be  input  by  the  analyst  in 
order  to  control  the  simulation  and  the  resultant  output  and  analyses. 

Since  the  actual  sequence  of  steps  required  to  get  from  one  program  to 
another  is  quite  complex,  there  is  an  executive  routine  that  manages  that 
transfer  of  data  between  the  programs  for  the  user.  The  executive  routine 
enables  any  step  to  be  executed  with  a  single  control  card  on  which  usually 
only  one  entry  changes.  Individual  control  cards  can  be  stacked  one  after 
another  and,  if  any  errors  occur  at  any  stage  in  the  sequence,  execution 
will  halt  at  that  step.  The  user  can  then  correct  the  error,  rerun  the 
step,  and  resume  processing  at  the  next  step  with  a  minimal  amount  of  con¬ 
cern  for  the  mechanics  of  interfacing  with  the  computer. 

4.1  THE  DECK  STRUCTURE  FOR  A  HOS  SIMULATION 

The  deck  structure  for  a  HOS  simulations  is  shown  in  Figure  49  . 
The  deck  consists  of  five  control  cards  that  are  always  used: 

(1)  A  job  card  to  identify  the  job  and  the  resources  required. 

(2)  An  account  card  to  control  billing  charges. 

(3)  A  PACKNAM  card  that  instructs  the  computer  operator  to  mount 
the  private  disc  pack  containing  the  HOS  programs. 

(4)  Two  GET  cards  that  access  the  disc  files  that  contain  the 
HOS  executive  routines. 
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Tallin  1.  Stajis  in  a  ItOS  Simulation. 


*  For  uw  only  by  those  with  extensive  HOS  ex|>erience. 
*•  Simulated  seconds:  CPU  seconds 


These  five  cards  are  then  followed  by  any  number  of  step  control  cards  that 
invoke  specific  steps  in  the  processing  sequence  and  by  the  data  cards  for 
each  step.  The  various  step  names  are  shown  in  Table  1,  which  also 
describes  the  function  of  each  step,  the  required  input  data  and  the  approximate 
time  and  memory  requirements  for  each  step.  The  steps  themselves  are 
described  below  in  more  detail. 

The  first  card  in  a  deck,  the  job  card,  assigns  a  name  to  the  job 
and  specifies  the  amount  of  core  and  CPU  time  required  by  the  job.  The 
time  required  for  a  job  consisting  of  several  steps  is  simply  the  sums  of  the 
times  required  for  each  step,  as  shown  in  Table  1.  The  core  required  is 
the  maximum  memory  required  by  any  individual  step.  Since  the  time  and 
memory  requirements  for  some  of  the  steps  can  vary  according  to  the 
complexity  of  the  simulation.  Table  1  shows  approximate  minimum  and 
maximum  values  or  formulas  that  can  be  used  to  estimate  the  amount  of  time 
and/or  memory  required.  The  minimum  values  are  based  on  the  radar  plotting 
problem  that  we  are  using  as  an  example.  The  maximum  values  are  based  on 
the  full  SS-3  simulation  from  which  this  problem  has  been  derived. 

One  step  control  card  is  needed  for  each  job  step.  The  last 

step  control  card  is  followed  by  a  ^80  card.*  The  ^8Q  card  is  followed  by 

any  data  required  by  Step  1.  This  data  is  terminated  by  another  8g  card, 

which  is  then  followed  by  any  data  for  Step  2,  etc.  The  last  set  of  data 

is  terminated  by  a  67Q  card.** 

°9 


*A  7,  8,  and  9  punched  in  column  1. 

**Some  steps  may  require  two  or  more  sets  of  data,  each  of  which  must 
be  separated  by  a  ^8g  card.  Some  steps  may  not  require  any  data,  in  which 
case  the  78g  card  for  that  step  must  be  omitted. 
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The  flow  of  steps  to  be  followed  in  order  to  run  a  complete  Simula 
tion  is  shown  in  Figure  50  .  These  steps  are  described  in  more  detail  in 
the  following  sections. 

4.2  STEP  HOPROC 

This  step  reads  in  the  HOPROC  instructions  describing  the  operator 
tasks.  It  assigns  a  sequence  number  to  each  instruction  so  that  it 
can  be  readily  referenced  in  case  corrections  must  be  made. 

The  data  for  this  step,  the  HOPROC  instructions,  can  be  either 
in  the  input  stream  or  on  a  file  already  on  the  disc.  If  the  data  are  in 
the  input  stream,  then  the  control  card  supplied  should  be: 

'CCExkc",  HOSEXEC,  HOPROC.  NAME  =  name,  FILE  =  INPUT 

where  name  is  a  one  to  four  character  identifier  chosen  by  the  analyst  to 
identify  the  simulation.*  If  the  instructions  are  already  on  a  system 
file,  then  tuo  control  cards  are  necessary: 


(CCEXEC,  HOSEXEC,  HOPROC. NAME  =  name,  FILE  =  filename 
("get/  filename. 

where  filename  is  the  name  of  the  (indirect)  file  on  which  the  instructions 
are  stored. 

The  first  statement  in  the  HOPROC  data  deck  must  be  preceded  by 
a  *DECK  card.  This  card  has  the  format: 

*0ECK  deckname 


*The  same  one  to  four  characters  must  be  used  in  all  succeeding  steps 
associated  with  the  simulation. 
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where  decknane  is  a  name  supplied  by  the  analyst  that  is  used  by  the  system 
to  label  the  HOPROC  statements.  The  first  card  in  the  HOPRQC  data  deck  is 
an  optional  SYSTEM  card  that  identifies  the  simulation  and  is  used  to  label 
the  pages  of  the  output.  The  second  card  is  an  optional  NO  DATA  DECK  card. 

This  card  tells  HAL  (when  it  is  executed)  to  omit  the  output  data  deck 

formats  for  HOS.  These  cards  are  followed  by  the  title  declarations  sections, 
functions  sections,  and  procedures  sections. 

4.3  STEP  HAL 

This  step  processes  the  code  entered  in  step  HOPROC  through  the 
HAL  program.  The  control  card  required  for  this  step  is: 

fcCEXEC,  HOSEXEC,  HAL.  NAME  *  name 

Data  for  this  step  is  optional  and  consists  of  any  final  HOPROC 
changes,  prepared  according  to  the  rules  described  in  Section  4.4 

4.3.1  The  Output  from  HAL 

There  are  four  major  sections  in  the  ouput  listings  obtained 

from  HAL: 

(1)  A  listing  of  the  HOPROC  data  deck  and  any  associated  error 
messages  identified  by  HAL. 

(2)  A  listing  of  the  dictionary  of  HOPROC  variable  names  and 
associated  data. 

(3)  Estimates  of  the  amount  of  core  that  will  be  needed  in 
steps  HOS  and  HODAC. 

(4)  A  list  of  the  data  cards  needed  for  HOS. 

Of  these  output  data,  the  most  important  are  the  listings  of  the 
HOPROC  inputs  and  associated  error  messages.  The  dictionary  of  variable 
names  is  frequently  used  to  explain  some  types  of  errors.  The  estimates  of 
the  HOS  and  HCDAC  core  requirements  and  the  listings  of  the  HOS  data  cards 
are  used  to  prepare  the  data  decks  for  succeeding  steps. 
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The  first  portion  of  the  HAL  output  is  a  listing  of  all  cards 
in  the  HOPROC  data  deck  and  any  associated  errors.  Syntax  errors  will 
generally  be  printed  on  the  line  immediately  following  the  line  on  which 
the  error  occurs.  However,  some  types  of  errors  may  not  be  identified 
immediately  by  the  HAL  program.  Such  an  error  ususally  generates  an  error 
message  that  does  not  point  clearly  to  the  source  of  the  error.  Generally, 
these  types  of  errors  are  the  result  of  spelling  mistakes  or  the  improper 
use  of  a  keyword  or  a  syntactic  structure.  Correcting  the  spelling  mis¬ 
take  or  the  sentence  structure  will  solve  the  proolem. 

When  a  serious  error  occurs,  HAL  will  usually  print  a  message 
stating  that  it  is  skipping  to  the  next  period,  semi-colon,  or  AND  in  the 
deck.  Consequently,  any  words  occurring  between  the  word  that  generated 
the  error  and  the  next  period,  semi-colon,  or  AND  will  not  be  checked  for 
syntactical  errors. 

The  error  messages  themselves  are  usually  self-explanatory  and 
are  identified  as  being  either  informative,  non-fatal ,  or  fatal.*  Although 
they  will  not  prevent  a  program  from  being  run  through  HOS,  informative  and 
non-fatal  errors  should  be  checked  carefully  because  they  generally  indicate 
a  non-standard  syntactic  usage  which  may  cause  the  compiled  program  to  do 
something  other  than  what  the  analyst  intended.  Typically,  what  will  happen 
is  that  an  informative  or  non-fatal  error  will  be  symptomatic  of  a  problem 
that  will  show  up  elsewhere  in  the  simulation  as  a  fatal  error.  Corrections 
to  the  data  deck  are  made  by  step  HOPMOD. 


*A  fourth  class  of  error  —  the  "compiler"  error  --  should  never  be 
encountered  by  the  general  user.  If,  however,  modifications  are  made  to 
the  current  statement  syntax,  compiler  errors  might  be  encountered  while 
the  modifications  are  being  debugged. 
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IP 


4.3.2  (A)  Step  HOPHOO 

This  step  enables  the  user  to  modify  the  HQPRQC  code  to  correct 
any  errors  identified  by  HAL.  The  control  card  for  this  step  is: 


!  CCEXEC,  HQSEXEC,  HOPMOD.  NAME  =*  name 

The  inputs  are  the  corrections  to  the  HOP ROC  code. 

The  correction  set  must  begin  with  an  #ID  card  (to  identify  the 
correction  set)  in  the  format: 


*10  ident 

The  *10  card  is  followed  by  the  set  of  corrections.  Two  basic  types  of 
corrections  can  be  made  to  the  HOPRQC  code  —  deletions  of  lines  (and  the 
optional  addition  of  lines  of  code  to  replace  the  lines  in  error)  and 
insertions  (to  add  completely  new  code).  To  delete  lines  of  code,  a  *0ELETE 
card  is  used:* 


(♦DELETE  deckname.seqno 

where  deckname.seqno  is  the  card  identifier  as  listed  on  the  output  from 
HAL.  A  series  of  consecutive  cards  can  be  deleted  by  entering  the  identifiers 
for  the  first  and  last  cards  to  be  deleted  as  follows: 


(•DELETE  deckname.seqno,  deckname.seqno 

The  *0ELETE  card  can  be  followed  by  any  number  of  lines  of  code 
to  be  added  in  place  of  the  code  being  deleted. 


•The  aobreviation  *0  can  be  used  in  place  of  *0ELE7E. 
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Code  can  be  added  without  deleting  lines  by  means  of  the  ‘INSERT 
card.*  This  card  has  the  format: 

/ 

[ * INSERT  deckname. segno 

Any  caras  entered  after  the  *INSERT  card  will  be  added  zfier 
the  card  named  on  the  ‘INSERT  card. 

4.3.3  The  HOPRQC  Variable  Dictionary 

The  second  portion  of  the  HAL  output  (Figure  51)  is  a  listing  of 
the  dictionary  of  HOPROC  variable  names.  The  numeric  data  associated  with 
the  dictionary  names  can  generally  be  ignored.  It  is  advisable,  however, 
to  check  the  dictionary  titles  to  make  certain  that  all  the  variables  have 
been  correctly  defined  and  that  there  are  no  unusual  or  unexpected  variable 
names  in  the  dictionary  --  a  statement  sometimes  gets  typed  in  a  way  such 
that  it  is  valid  HOPROC  syntax,  but  not  what  was  intended.  Such  errors 
can  often  be  spotted  by  scanning  the  dictionary. 

4.3.4  HAL  Estimates  of  HOS  and  HODAC  Core  Requirements 

The  next  page  of  output  from  HAL  (Figure  52)  estimates  the  amount 
of  core  needed  by  steps  HOS  and  HODAC.  These  estimates  should  be  entered 
on  the  job  card  when  these  steps  are  run. 

The  HOS  estimate  is  a  rough  approximation  of  the  amount  of  core 
needed  --  it  should  be  considered  to  be  the  minimum  amount  that  will  prob¬ 
ably  be  needed.  The  problem  with  estimating  the  HOS  core  requirement  is 
that  HAL  has  no  way  of  telling  how  much  machine  code  the  hardware  and 
operator  functions  will  generate.  If  the  functions  are  much  more  complicated 
than  is  usual  or  if  they  use  large  user-defined  arrays,  then  HOS  will  require 
more  core  than  the  amount  estimated  by  HAL.  A  simulation  with  a  simple  set 
of  functions  will  require  approximate! y  the  estimated  amount. 


*The  abbreviation  *1  can  be  used  in  place  of  ‘INSERT. 
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The  core  estimates  for  HODAC  are  accurate,  but  the  user  should 
note  that  one  of  the  analysis  programs,  the  Devices  By  Procedure  Analysis 
requires  more  core  than  any  of  the  other  analyses  and  could  conceivably 
require  more  core  than  is  available  on  the  computer. 

4.3.5  The  HOS  Crewstation  Data  Deck  Formats 

The  final  section  of  output  from  HAL  is  only  printed  when  the 
HOPROC  statements  are  error-free  or  if  a  HOS  DATA  DECK  card  is  entered  after 
the  SYSTEM  card  and  before  the  first  HOPROC  statement.*  This  output  lists 
the  data  cards  required  to  execute  HOS.  The  format  of  the  listings  is  such 
that  the  required  data  can  be  filled  in  and  given  to  a  keypuncher  who  can 

then  punch  the  necessary  data  cards  directly  from  the  listings.  Figures  52 
through  59  are  the  listings  of  the  HOS  data  deck  formats  for  the  radar 
plotting  problem.  On  each  page,  certain  lines  are  marked  with  asterisks  in 
the  left-most  column.  The  asterisks  indicate  which  lines  are  to  be  punched  - 
all  the  other  lines  simply  describe  the  data  to  be  entered  on  each  card. 
Furthermore,  some  of  the  cards  marked  with  an  asterisk  do  not  necessarily 
have  to  be  used  —  i.e. ,  some  of  the  cards  are  optional,  and  HOS  will  supply 
default  values  for  these  data  items  if  the  cards  are  omitted. 

4.3. 5.1  The  SYSTEM  Card  (Figure  53) 

The  user  can  enter  a  title  on  the  optional  SYSTEM  card  that  will 
identify  the  data  deck  and  that  will  be  used  by  HOS  to  label  its  output. 

If  the  SYSTEM  card  is  not  used,  HOS  will  label  the  output  with  the  title 
that  was  used  on  the  HAL  SYSTEM  card  (if  a  HAL  SYSTEM  card  was  used). 


♦Printing  of  the  data  deck  after  an  error-free  set  of  HOPROC  instruc¬ 
tions  can  be  suppressed  by  entering  a  NO  DATA  DECK  statement  after  the 
SYSTEM  card. 
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Figure  63.  HOS  data  deck  ganaral  spadl 
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Figure  56.  HOS  date  deck  symbol  section. 
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Figure  60.  HOS  data  deck  optional  data. 


Figure  61.  The  design  eye  reference  coordinate  system. 
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4. 3. 5. 2  (A)  The  READ  INPUTS  Card  (Figure  53) 

Processing  the  HOS  data  deck  is  a  potentially  time  consuming 
process.  Therefore,  as  the  data  deck  for  a  particular  problem  is  being 
processed,  HOS  outputs  the  data  to  a  file.  If  the  same  problem  is  rerun 
with  only  minor  modifications.  HOS  can  obtain  the  bulk  of  the  inputs  from 
the  data  file  that  it  created  on  the  earlier  run,  thereby  saving  a 
significant  amount  of  computer  time.  When  this  option  is  used,  the  analyst 
need  only  enter  those  inputs  that  are  different  from  the  earlier  run.  The 
READ  INPUTS  card  tells  HOS  to  use  the  data  from  the  file  of  processed  inputs 
and  to  expect  only  changes  to  that  file. 

4.3. 5. 3  (A)  The  CHECKPOINT  Card  (Figure  53) 

The  MILESTONE  statement  generates  a  CHECKPOINT  file  that  contains 
all  the  data  HOS  needs  to  resume  processing  at  the  MILESTONE.  The  CHECKPOINT 
card  identifies  the  checkpoint  file  number  (printed  in  the  HOS  listings  at 
the  time  the  MILESTONE  instruction  is  executed)  at  which  processing  is  to 
resume.  Crewstation  data  cards  can  be  entered  after  the  CHECKPOINT  card  to 
modify  any  of  the  crewstation  data. 

4. 3. 5. 4  (A)  The  METRIC/ENGLISH  Card  (Figure  53) 

Data  on  display,  control,  and  symbol  locations  are  stored  intern¬ 
ally  in  HOS  in  inches,  referenced  to  a  coordinate  system  centered  at  the 
Design  Eye  Point  and  oriented  as  shown  in  Figure  61. 

Since  data  from  blueprints  or  other  sources  may  reference  the 
locations  of  displays,  controls,  and  symbols  to  a  point  other  than  the 
Design  Eye  Point  and  may  use  metric  measurements  rather  than  English  units, 
HOS  allows  the  user  to  specify  an  alternate  point  from  which  the  device 
locations  are  to  be  measured.  This  alternate  reference  point  is  entered 
on  the  optional  METRIC/ENGLISH  card,  which  also  indicates  whether  a  metric 
to  English  conversion  is  needed. 
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For  example,  the  card 


ENGLISH  19.6  20.2  35.0 

Indicates  that  the  display,  control,  and  symbol  coordinates  are  In  Inches 
and  are  measured  from  a  point  whose  X,  Y,  and  Z  coordinates  are  displaced 
19.6,  20.2,  and  35.0  inches  from  the  Design  Eye  Point.  The  card 

METRIC  25  50  0 

says  that  the  coordinates  are  in  centimeters,  measured  from  a  point  whose 
X,  Y,  and  Z  coordinates  are  displaced  25,  50,  and  1  cm,  respectively,  from 
the  Oeslgn  Eye  Point. 

4. 3. 5. 5  The  Oi splay,  Control,  and  Symbol  Sections 

These  display,  control,  and  symbol  sections  of  the  HOS  crewstatlon 
data  deck  (Figures  54  through  56)  are  used  to  enter  data  on  the  displays, 
controls,  and  symbols  in  the  operator's  crewstatlon.  The  most  important 
items  of  information  entered  in  these  sections  are  the  modal  number  of  the 
display,  control,  or  symbol  and  Its  X,  X,  and  2  coordinates. 

The  model  number  refers  to  the  entry  in  the  Model  Specifications 
Section  (see  Section  4.3.5. 7)  that  corresponds  to  the  specific  piece  of 
equipment  being  described.  Assume,  for  example,  that  several  controls  repre¬ 
sent  a  specific  type  of  toggle  switch.  That  type  of  toggle  switch  would  be 
assigned  a  model  number  and  would  be  described  in  the  model  specifications 
section.  All  controls  that  are  that  type  of  toggle  switch  would  be  assigned 
the  same  model  number. 

The  X,  Y,  and  Z  coordinates  must  be  given  with  respect  to  the 
units  and  reference  point  identified  on  the  METRIC/ENGLISH  card.  If  no 
METRIC/ENGLISH  card  was  used,  the  X,  Y,  and  Z  coordinates  must  be  in  Inches 
from  the  Design  Eye  Point  with  the  axes  oriented  as  shown  in  Figure  61. 

The  other  parameters  on  the  display,  control,  and  symbol 
section  cards  are  the  initial  hab  strength  (usually  zero),  the  initial  state 
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(either  zero  for  inactive  or  one  for  active),  the  initial  criticality  (a 
value  between  zero  and  one),  and  the  initial  value  (or  setting)  of  the  dis¬ 
play,  control,  or  symbol.  Advice  on  the  establishment  of  the  hab  strength 
and  criticality  parameter  values  is  presented  in  the  Appendix. 

Generally,  one  data  card  must  be  entered  for  every  display,  con¬ 
trol,  symbol  or  symbol  characteristic  in  the  crewstation.  The  exception  to 
this  rule  is  that  a  single  data  card  may  be  used  for  all  the  elements  in  a 
group  or  subgroup  if  every  element  in  the  group  or  subgroup  has  the  same  set 
of  initial  values  for  symbols  and  symbol  characteristics. 

4.3. 5.6  The  Operator  Functions  Section  (Figure  56  ) 

Data  for  the  operator  functions  is  comparable  to  that  for  the  displays, 
controls,  and  symbols  with  the  exception  that  no  X,  Y,  and  Z  locations  are 
specified.  In  addition,  instead  of  a  model  number,  a  function  type  must  be 
specified.  The  function  type  indicates  whether  the  value  of  the  function  is 
real  or  integer  and  whether  the  function  value  is  extrapolatable  or  not. 

4. 3. 5. 7  The  Model  Specifications  Section 

The  primary  function  of  the  Model  Specifications  Section  is  to 
provide  a  generic  listing  of  the  types  of  displays,  controls,  and  symbols  used 
in  the  crewstation  and  their  operating  characteristics.  A  sample  Model 
Specifications  Section  is  shown  in  Figure  57.  As  more  experimentation  is 
done  with  HOS  and  with  specific  display/ control /symbol  characteristics,  we 
expect  that  we  will  ultimately  be  able  to  develop  a  "standard"  set  of  model 
specifications  that  will  contain  the  data  needed  to  model  any  standard 
display,  control,  or  symbol  accurately. 

The  data  on  the  Model  Specification  data  cards  include: 

•  The  body  part  (eyes,  eyes/hands,  hands,  or  feet)  needed  to 
absorb  and/or  manipulate  the  device. 

•  The  accuracy  with  which  the  device  can  be  absorbed  and/or 
manipulated  (i.e.,  the  percent  tolerance  on  absorptions 
and  manipulations). 

•  The  micro-absorption  time  charge. 

•  The  size  of  the  device. 

•  The  model  type  (real /integer,  extrapolatable/not- 
extrapolatabl e) . 

•  Control  specific  data  —  e.g.,  rotation  limits,  forces,  etc. 
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4.3. 5.3  Human  Operator  Specifications  (Figure  58) 

The  next  section  of  the  data  deck  defines  certain  of  the  characteris¬ 
tics  of  the  HOS  operator  —  the  Initial  (relaxed)  locations  of  the  operator's 
eyes,  hands,  feet,  shoulders,  and  hips,  the  lengths  of  the  operator's  arms 
and  legs,  and  the  maximum  distance  from  the  operator's  eye  fixation  point 
at  which  an  object  will  still  be  assumed  to  be  "in  focus." 

4.3. 5.9  Run  Parameters  (Figure  59) 

This  optional  card  assigns  data  values  to  some  of  the  parameters 
used  within  the  HOS  program. 

4.3.5.10  The  PRINT/SUPPRESS  MESSAGES  Cards  (Figure  59) 

These  cards  control  how  "verbose"  the  output  from  HOS  will  be. 

Either  card  can  be  used  to  control  which  messages  will  be  printed  by  the 
program  and  which  will  be  omitted. 

4.3.5.11  The  ACTIVE/INACTIVE  MILESTONES  Cards  (Figure  59) 

These  cards  specify  which  MILESTONE  instructions  will  generate 
listings  of  the  dictionary  arrays  In  HOS. 

4.3.5.12  The  TIMED  MILESTONES  Card  (Figure  59) 

This  card  can  be  used  to  generate  printouts  of  the  HOS  dictionary 
arrays  at  specific  times  during  the  simulation. 

4.3.5.13  The  TIMED  SNAPSHOTS  Card  (Figure  59) 

This  card  is  used  to  suppress  simulation  outputs  for  certain  time 
periods  and  to  print  them  for  other  periods. 

4.3.5.14  The  TIMED  ENDPOINT  Card  (Figure  59) 

This  card  will  automatically  terminate  the  simulation  at  the 
specified  simulation  time. 
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4.3.5.15  The  PLOT  Cards  (Figure  59) 

The  DON'T  PLOT  ASTERISKS,  PLOT  ASTERISKS,  and  PLOT  ALL  DATA 
cards  are  used  to  control  the  data  sent  by  HOS  to  the  HODAC  plotting  routines. 

4.4  STEP  HALHOS 

Step  HALHOS  is  run  after  the  HOPROC  statements  have  been  success¬ 
fully  run  through  HAL.  It  is  at  this  step  that  the  crewstation  data  des¬ 
cribed  in  the  preceding  sections  is  entered.  In  addition,  data  that  will  be 
needed  by  HOS  at  execution  time*  can  also  be  entered  at  this  time  as  can 
any  additional  FORTRAN  code  not  already  in  the  program  (e.g.,  user-supplied 
subroutines,  etc.).  The  control  card  needed  to  execute  this  step  is: 

CCEXEC,  HOSEXEC,  HALHOS.  NAME  *  name 

The  first  set  of  input  data  for  this  step  must  be  the  crewstation 

data.  If  there  is  any  run-time  data  to  be  supplied,  this  must  be  entered 

after  the  78Q  card  that  terminates  the  crewstation  data,  If  there  is  no 
’  7 

run-time  data,  there  must  be  cm  extra  8  ^  card  in  the  data  deck,  unless  this 

step  is  the  last  step  in  the  run  or  unless  any  succeeding  steps  do  not 

require  any  input  data,  in  which  case  the  crewstation  data  will  be  terminated 

by  a  67q  card. 

89 

Following  the  run-time  data  (or  the  78g  card  that  holds  its  place), 

the  analyst  can  enter  any  additional  FORTRAN  code  modifications  that  may  be 

needed  for  a  simulation.  If  there  are  no  FORTRAN  code  modifications,  there 
7 

must  be  cm  extra  8 g  card  in  the  data  deck,  unless  this  step  is  the  last  step 

in  the  run  or  unless  any  succeeding  steps  do  not  require  any  input  data,  in 

which  case  the  modifications  will  be  terminated  by  a  87Q  card. 

°9 

♦Hardware  and  operator  functions  may  need  data  at  execution  time.  This 
data  is  read  by  the  functions  from  logical  unit  7. 
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4.5  (A)  STEP  HOSMOD 

Any  FORTRAN  errors  in  the  hardware  or  operator  functions  will  be 
Identified  by  step  HALHOS.  These  errors  can  be  corrected  either  by  re-run¬ 
ning  the  HOPROC  code  through  HAL  (using  either  HOPMOD  to  correct  the  HOPROC 
code  or  by  correcting  the  original  HOPROC  deck  and  starting  all  over  again) 
or  by  correcting  the  FORTRAN  directly  using  step  HOSMOD.  Correcting  anything 
more  them  simple  FORTRAN  errors  in  this  way  (i.e.,  making  changes  directly 
to  the  NOS  code  or  the  data  generated  by  HAL)  is  reconmended  only  for  those 
having  advanced  experience  with  SOS  and  with  FORTRAN  programing.  The  control 
card  needed  to  run  step  H0SM00  Is: 

ICCEXEC,  HOSEXEC,  H0SM00.  NAME  >  name 

The  data  to  be  entered  in  this  step  are  the  deletions  and  inser¬ 
tions  to  the  HOS  FORTRAN  code  or  to  the  data  generated  by  HOS.  This  correc¬ 
tion  set  follows  the  same  general  rules  described  for  the  correction  set 
used  in  step  HOPMOO.  If  step  HALHOS  has  just  been  run  and  has  identified 
any  FORTRAN  errors  In  the  hardware  or  operator  functions,  the  following 
data  cards  are  required  after  the  78g  card  that  terminates  the  set  of 
corrections: 


*0  COS/HFUNC  j if  there  were  FORTRAN  errors 

*1  REL/HARSIM,  REl/HFUNC  (in  the  hardware  functions  (HFUNC) 

*0  COS /MFUNC  |1f  there  were  FORTRAN  errors 

*0  REl/KIND,  REL/MFUNC  i  in  the  operator  functions  (MFUNC) 

These  cards  are  needed  only  until  both  HFUNC  and  MFUNC  have  been 
successfully  compiled  once.  However,  even  after  HFUNC  and  MFUNC  have  been 
successfully  compiled,  an  extra  78g  card  will  be  needed  after  the  correction 
set,  if  there  are  succeeding  steps  that  have  inputs. 
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Warring:  If  the  first  set  of  corrections  to  the  FORTRAN  code 
fails  to  correct  all  the  errors,  then  none  of  the  changes  entered  will  have 
been  made  permanent  —  i.e.,  the  same  changes  will  have  to  be  entered 
again  along  with  any  additional  changes  needed  to  make  the  subroutines 
compile  successfully. 

4.6  STEP  HOS 

This  step  executes  the  HOS  program.  The  following  control  card 

is  used: 

fCCEXEC,  HOSEXEC,  HOS.  NAME  *  name 
Normally,  no  additional  inputs  are  required. 

4.6.1  The  Output  from  HOS 

Figures  62  through  64  are  examples  of  the  outputs  from  HOS 
for  the  radar  plotting  simulation.  There  are  three  major  sections  to  the 
HOS  outputs: 

(1)  Listings  of  the  input  arrays  passed  from  HAL  to  HOS 
(Figure  62  ). 

(2)  Listings  of  the  crewstation  input  data  and  any  associated 
error  messages  (Figure  63  ). 

(3)  The  simulation  results  (Figure  64  ). 

The  data  arrays  (Figure  62  )  passed  from  HAL  to  HOS  will  generally 
be  of  little  concern  to  the  novice  HOS  user.  Those  with  more  HOS  experience 
can  use  these  data  to  make  simple  corrections  to  the  HOPROC  instructions, 
thereby  avoiding  the  need  to  rerun  HAL. 

The  crewstation  data  (Figure  63  )  consists  of  listings  of  the 
data  cards  prepared  by  the  analyst  in  accordance  with  the  formats  output 
by  HAL.  If  there  are  any  errors  on  these  cards,  HOS  will  output  a  diagnostic 
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Flgura  62.  Array*  Input  to  HOS  from  HAL. 
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Figun  63.  CrdwtUlkm  Input  Data  (Cont-l 


message  immediately  after  each  card  that  is  in  error.  These  errors  will 
usually  not  prevent  the  simulation  from  beginning  its  execution,  but  they 
will  ultimately  result  in  problems  that  must  be  corrected  in  order  to 
obtain  an  error-free  simulation. 

The  simulation  output  itself  (Figure  64  )  can  be  quite  extensive 
and  usually  must  be  studied  carefully  in  order  to  ensure  that  both  the 
operator  and  the  system  are  behaving  as  they  should.  If  one  or  the  other 
are  not  behaving  properly,  changes  to  the  HOPROC  instructions  or  to  the 
input  data  will  generally  be  required.  The  simulation  output  is  subdivided 
into  two  major  column  headings  —  one  column  listing  the  operator  actions, 
the  other  column  listing  hardware  actions.  The  current  simulation  time  is 
printed  at  the  left-hand  edge  of  the  page.  Next  to  the  simulation  time 
are  the  actions  being  taken  by  the  operator.  These  actions  are  shown  indented 
under  the  procedure  name  that  is  currently  being  executed.  Statement  labels, 
IF,  and  ALTER  statement  numbers  are  also  indicated  so  that  the  progression 
of  actions  through  the  procedures  can  be  followed.  In  addition,  when¬ 
ever  the  operator  absorbs  or  remembers  the  value  of  a  device  or  function, 
the  new  estimated  value  is  shown.  Thus  the  analyst  can  readily  see  what 
the  operator  believes  the  value  of  a  device  or  function  to  be  throughout 
the  simulation. 

In  the  center  of  the  page  there  is  a  column  that  indicates  which 
body  part  the  operator  is  using  to  accomplish  the  indicated  action.  This 
column  can  be  used  to  check  that  the  appropriate  body  parts  are  being  used 
for  the  appropriate  functions  (i.e.,  that  the  crewstation  data  deck  has 
been  properly  prepared).  It  can  also  be  used  to  estimate  the  loading  on 
each  of  the  operator's  channels.* 


*However,  the  HODAC  Channel  Loading  Report  presents  this  information 
in  a  much  more  concise  format. 
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the  actual  values  of  the  devices  being  used  by  the  operator  whenever 
the  operator  absorbs  or  recalls  any  information. 

A  final  type  of  output  that  can  be  obtained  from  HOS  is  shown 
in  Figure  65.  This  report  is  generated  whenever  an  active  MILESTONE  or 
ENDPOINT  is  encountered.  The  output  lists  all  the  major  arrays  that  are 
being  used  by  HOS  —  e.g.,  the  X,  Y,  and  Z  locations  of  all  displays,  con¬ 
trols,  and  symbols,  their  estimated,  desired,  and  actual  values,  etc.  It 
.also  lists  the  current  values  of  all  operator  and  hardware  functions,  the 
names  of  all  the  operator  procedures  currently  on  the  active  procedure  list, 
the  locations  of  each  of  the  major  body  parts,  what  each  body  part  is 
doint,  and  when  it  will  complete  whatever  it  is  doing. 

4.6.2  (A)  Starting  from  a  Checkpoint 

When  a  MILESTONE  instruction  is  executed,  a  checkpoint  is  generated. 
Execution  can  be  restarted  at  the  chekcpoint  by  including  a  CHECKPOINT  card 
in  the  input  stream.  This  card  has  the  format: 

CHECKPOINT  checkpoint-number 

Input  cards  can  be  entered  after  the  CHECKPOINT  card  to  modify 
any  of  the  crewstation  data. 

4.6.3  (A)  Bypassing  Crewstation  Input  Processing 

After  the  crewstation  inputs  have  been  processed  once  (whether 
or  not  there  were  errors  in  the  inputs)  the  bulk  of  the  input  data  processing 
can  be  bypassed  by  the  use  of  the  READ  INPUTS  card.  If  there  are  any 
corrections  to  the  crewstation  data,  these  can  be  entered  immediately  after 
the  READ  INPUTS  card. 


209 


MILESTONE/ENDPOINT  Output. 


i 


U  3  0-303 

^  00030 

«  0  0  3  0  0 


im  f-  r-  n  x 
T  ?  ^  X  o 
x  —  if 


a. 

m» 

/»  if 

X 

-P 

4* 

fl 

/» 

a 

vr- 

m  <*> 

X 

X 

X 

X 

U 

• 

• 

• 

• 

• 

*m 

c 

o 

IT 

a* 

MM 

mm 

mm 

c 

rvj 

M* 

M 

o 

a 

o 

o 

c  o 

O 

a 

(j 

• 

x 

• 

— J 

O  uP 

o 

<\l  o 

mm 

• 

• 

• 

• 

* 

Ui 

< 

o  rvj 

a 

r*»  if 

im  — 

r*» 

n 

O  O 

o  o 

3 

2 

•  • 

• 

•  • 

—  M 

f» 

M 

x  o 

*0  o 

C 

—  if 

•  • 

•  ^ 

•  • 

•  • 

-J 

(J 

r 

•m  ~ 

4  o 

(M 

r\j 

< 

r* 

1  • 

1  • 

mm 

x 

x 

1 

r* 

<f 

mm 

mm 

m 

mm 

V 

a 

II 

It 

II 

u. 

M- 

>-  II 

>-  II 

M- 

z 

if 

a 

41 

<  M> 

<4  N» 

«  M- 

« 

if 

c 

w 

Z 

u 

" ■ 

M» 

C 

c 

>»  U- 

V  u. 

M  Ui 

>  Ui 

>*  U 

■“ 

2 

■—  «_ 

U 

-  X 

w  X 

-I  X 

-l  X 

M  X 

a 

►- 

>“  o 

u 

M>  ■— 

^  PM 

— 

N-  — 

M*  ■— 

m- 

if 

Z 

X 

mm  mm 

Z  H. 

Z  H. 

Z  N- 

Z  Mi 

Z  1- 

z 

c 

u. 

M» 

f  m* 

a 

u. 

Ui 

u 

w 

Ui 

a 

X  if 

a 

c  — 

a 

a  ►- 

X  M. 

X  *- 

z  ^ 

z 

> 

M»  >» 

u-  a  f 

z 

a  « 

a  * 

X  < 

£Z  < 

a  < 

m 

-j 

x 

<  mm 

vu 

c 

u 

c 

X 

-j 

« 

X  z 

3 

-» a. 

> 

M 

C  w 

C  Ik 

u  u 

C  u 

C  ui 

< 

< 

z 

mm 

if 

-i 

M 

if 

Ui 

Ui 

u 

Ui 

z 

(X 

c 

►-  J 

<  c 

N» 

if 

<Z 

c  a 

X 

*“  CE 

a 

c 

Mi 

u 

a 

x  u 

(J 

Mi 

u. 

z  u 

a  u 

O  U 

M-  U 

■■ 

X 

N- 

O  * 

« 

* 

< 

T 

< 

2 

o 

o 

u 

u 

a  c 

c 

*  c 

Ui 

£  u 

<  u 

u  u 

C  Ui 

u 

< 

M 

•«  c 

4C 

u  O 

a 

X 

£  X 

£ 

W  X 

“• 

X 

2 

m-  z 

X 

Z  £ 

-X 

c 

M* 

if 

(f  — j 

£  -* 

^  -J 

£  mi 

>-  mi 

Ui  mi 

C  -J 

U  -J 

U  «J 

if!  X 

r* 

X  * 

>  — 

■X  «M 

Ui  »— 

<X  4 

4 

4  4 

Ui  3 

X  * 

-J  1 

a  z 

MJ  9 

m 


The  READ  INPUTS  card  and  CHECKPOINT  card  cannot  be  used  together 
(the  CHECKPOINT  card  has  the  effect  of  bypassing  the  crewstation  input 
processing). 

4.5.4  (A)  HOS  Run-Time  Inputs 

The  hardware  and  operator  functions  normally  accept  run-time 
inputs  from  logical  unit  7.  Supplementary  inputs  can,  however,  be  read 
in  on  logical  unit  5  if  the  user  precedes  them  by  an  extra  78g  card  (to 
separate  them  from  the  CHECKPOINT,  READ  INPUTS,  or  other  crewstation  data 
cards  that  could  potentially  appear  in  the  input  stream  at  this  point). 

4.7  STEPS  HALHOO  AND  HOOAC 

Step  HALHOO  uses  the  data  supplied  by  HAL  to  prepare  the  HOOAC 
Analysis  Program  for  execution.  Step  HOOAC  executes  the  HOOAC  program. 

Since  one  of  the  HOOAC  analyses,  the  Devices  By  Procedure  Analysis,  requires 
a  different  version  of  the  HOOAC  program  than  the  other  analyses,  steps 
HALHOD  and  HODAC  have  to  be  executed  twice  to  obtain  all  the  available  HOOAC 
analyses.  The  following  control  cards  are  used  to  obtain  any  analysis  other 
than  the  Devices  8y  Procedure  Analysis: 


fCCEXEC,  HOSEXEC,  HOOAC.  NAME  »  name,  RUN  *  0 

> 

fCCEXEC,  HOSEXEC,  HALHOD.  NAME  »  name,  RUN  *  0 

The  following  control  cards  are  used  to  obtain  the  Devices  By 
Procedure  Analysis: 


fCCEXEC,  HOSEXEC,  HODAC. NAME  *  name,  RUN  *  1 
fCCEXEC,  HOSEXEC,  HALHOD. NAME  *- name,  RUN  *  1 

4.7.1  The  Timeline  Analysis  (Figure  66) 

The  HODAC  Timeline  Analysis  provides  a  summary  of  the  primary 
actions  performed  by  the  operator  within  a  specific  interval,  termed  a 
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snapshot  interval.  At  the  top  of  the  page,  HQOAC  lists  the  date,  the  name 
of  the  simulation,  and  the  snapshot  interval.  Across  the  page  are  headings 
for  the  simulation  time,  the  procedure  currently  being  executed,  and  each 
body  part.  Down  the  page  are  the  simulation  times,  the  primary  procedure 
being  executed  within  that  snapshot  interval,  and  the  primary  functions 
being  performed  by  each  body  part  during  the  snapshot  interval.  Note  that 
the  primary  function  is  defined  as  that  function  requiring  most  of  the 
operator's  time  during  that  snapshot  interval. 

A. 7. 2  The  Channel  Loading  Report 

The  Timeline  Analysis  identifies  the  primary  actions  performed 
by  the  operator  within  each  snapshot  interval.  Examining  the  report  can 
help  to  determine  how  busy  the  operator  is  at  any  particular  time.  However, 
since  the  Timeline  Analysis  identifies  the  primary  activity  performed  in 
any  snapshot  interval,  it  does  not  indicate  how  much  of  that  interval  was 
actually  spent  performing  that  activity  (or  any  activity  other  than  the 
primary  activity).  This  data  Is  provided  by  the  Channel  Loading  Report. 

This  report  (Figure  67  )  indicates  the  percent  of  time  that  each  body  part 
spends  on  any  activity  within  a  specific  snapshot  Interval. 

4.7.3  The  Device  3y  3ody  Parts  Analysis 

The  Oevice  Analysis  by  Body  Parts  is  closely  related  to  the  Timeline 
Analysis  and  the  Channel  Loading  Analysis.  The  report  (Figure  68)  tabulates 
statistics  on  the  amount  of  time  each  of  the  operator’s  body  parts  spends 
performing  certain  types  of  tasks  related  to  each  device.  The  name  of  the 
device  is  listed  in  the  leftmost  column.  Each  device  generates  three  lines 
of  output.  The  first  line  contains  the  times  associated  with  moving  to  and, 
if  necessary,  grasping  the  device.  The  second  line  contains  the  times 
associated  with  absorbing  the  value  of  the  device.  The  third  line  contains 
the  amounts  of  times  associated  with  manipulating  the  device.  The  times 
are  listed  underneath  the  column  headed  by  the  appropriate  body  part.* 


♦The  "manipulation''  times  listed  under  "EYES"  column  is  actually  the 
amount  of  time  spent  recalling  the  value  of  the  device,  since  the  operator's 
eyes  cannot  be  used  in  manipulations. 
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Statistics  are  presented  in  a  format  that  is  standard  for  most  of  the 
remaining  HODAC  reports.  The  format  gives  the  total  amount  of  time  spent 
on  the  activity,  the  number  of  times  the  activity  was  performed,  the  mean 
value  for  the  activity,  and  the  standard  deviation.  Thus,  as  shown  in 
Figure  68  ,  the  operator  spends  a  total  of  4.5  seconds  manipulating  the 
ENTER-RADAR-CONTACT  control  with  his  right  hand.  He  performs  10  manipulations 
for  an  average  manipulation  time  of  .45  seconds  with  a  standard  deviation 
of  .15  seconds. 

4.7.4  The  Device  Analysis  By  Usage  (Figure  69) 

The  Device  By  Usage  Analysis  generates  statistics  on  the  amounts 
of  time  spent  by  the  operator  in  specific  actions  associated  with  each  of 
the  devices  in  the  crewstation.  It  thus  provides  composite  statistics  for 
the  actions  presented  in  the  devices  by  body  part  analysis  and,  in  addition, 
provides  statistics  on  activities  that  may  have  required  several  body  parts  -- 
for  example,  enabling  a  display  or  control.  The  format  of  the  report  is 
similar  to  that  of  the  Device  By  Body  Parts  Analysis.  The  left-most  column 
identifies  the  device.  The  remaining  columns  list  the  total  times,  number 
of  times,  means  and  standard  deviations  for  each  of  the  usages  identified 
at  the  TOP  of  the  page.  The  meanings  of  each  of  these  usages  are  as  follows: 


Moving/Grasping 

Absorbi ng/Computi ng 

Manipulating 

Recalling 

Enabl ing 


The  time  spent  moving  a  body 
part  to  a  device  and  (if  required) 
grasping  it. 

The  time  spent  reading  a  device 
or  computing  a  function. 

The  time  spent  manipulating  a 
control . 

The  time  spent  recalling  (or 
attempting  to  recall)  the  value 
of  a  device  or  function. 

The  time  spent  working  on  the 
procedure  that  enables  the 
device  or  function. 
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Adjusting  The  time  spent  working  on  the 

procedure  that  adjusts  the 
device  or  function. 

Disabling  The  time  spent  working  on  the 

procedure  that  disables  the 
device  or  function. 

Stymied-Absorption  The  time  spent  outside  the  cur¬ 

rent  procedure  as  a  consequence 
of  being  unable  to  read  the 
value  of  a  device  at  the  time 
it  was  needed. 

Stymied-Manipulation  The  time  spent  outside  the  cur¬ 

rent  procedure  as  a  consequence 
of  being  unable  to  manipulate 
the  device  when  needed. 

4.7.5  The  Device  By  Procedure  Analysis  (Figure  70) 

The  Device  By  Procedure  Analysis  sumnarizes  the  t  nes  spent  by 
the  operator  on  the  same  actions  as  in  the  Device  By  Usage  Analysis.  The 
difference  between  the  two  is  that  in  the  Devices  By  Procedures  Analysis, 
the  actions  are  broken  down  by  procedure,  as  well  as  by  usage. 

4.7.6  The  Procedures  Analysis  (Figure  71) 

The  Procedures  Analysis  also  presents  usage  statistics.  However, 
in  this  case,  the  data  is  summed  over  all  actions  performed  within  a  pro¬ 
cedure  rather  than  over  procedures.  In  addition,  the  Procedures  Analysis 
accumulates  statistics  on  certain  types  of  activities  that  only  have 
significance  at  the  procedural  level. 

4.7.7  Label  Analysis  (Figure  72) 

The  HODAC  Label  Analysis  provides  certain  suntnary  data  for  pro¬ 
cedures  and,  in  addition,  tabulates  data  pertaining  to  certain  procedure 
activities.  The  suimary  data  for  each  procedure  includes  the  times  at  which 
procedures  were  first  and  last  activated,  the  times  at  which  they  were 
first  and  last  executed,  and  the  times  at  which  they  were  first  and  last 
removed  from  the  active  procedure  list. 


The  with  in- procedure  times  are  predicated  on  the  assumption  that 
labeled  statements  within  a  procedure  identify  significant  blocks  of  code 
within  the  procedure.  Consequently,  the  data  accumulated  in  association 
with  these  labels  describe  how  frequently  these  blocks  of  code  within  a 
procedure  are  executed  and  how  long  each  execution  requires.  The  column  en¬ 
titled  "TOTAL  TIME  TO"  gives  the  amount  of  time,  number  of  times,  mean  and 
standard  deviations  that  it  took  between  the  time  a  procedure  was  activated 
and  the  time  that  the  label  was  encountered.  The  column  headed  "ACTIVE  TIME 
TO"  gives  the  total  amount  of  time,  number  of  times,  mean  and  standard 
deviation  between  the  time  the  procedure  began  execution,  and  tne  time  the 
labeled  statement  was  encountered.  Consequently,  these  columns  will  always 
contain,  at  most,  a  single  count  for  each  activation  of  a  procedure. 

The  column  headed  "NUMBER  OF  ENCOUNTERS"  tabulates  the  number 
of  times  per  execution  that  the  labeled  statement  was  encountered.  This 
number  is  indicative  of  the  frequency  with  which  a  particular  section  of 
code  was  executed.  Finally,  the  last  column,  "ENCOUNTERS,"  indicates  the 
number  and  percent  of  times  the  labeled  statement  was  executed  for  each 
distinct  execution  of  the  procedure. 

These  statistics  can  have  important  consequences  when  one 
attempts  to  determine  the  training  requirements  for  a  specific  system.  In 
particular,  they  indicate  how  much  concentration  should  be  placed  on  training 
operators  on  certain  routine  operations. 

4.7.8  The  Link  Analysis  (Figures  73  and  74) 

In  the  HODAC  Link  Analysis,  the  analyst  defines  groups  of  displays 
and  controls.  HODAC  will  then  accumulate  statistics  on  the  number  of 
operator  "transitions"  from  group  to  group  and  within  each  group.  These 
statistics  include: 

•  Times  for  moving  a  body  part  from  an  element  in  one  group 
to  an  element  in  another  group. 
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Figure  73.  HODAC  link  analysis. 


Figure  74.  HOOAC  link  analysis. 


•  Total  times  that  a  body  part  is  idle  and/or  dwelling  in 
a  particular  group. 

•  Link  frequencies  (i.e.,  the  percentage  of  all  movements  of 
a  body  part  that  are  within  a  particular  group  or  are  from 
one  particular  group  to  another). 


4.7.9  Inputs  to  HODAC 

The  only  inputs  required  by  HODAC  are  the  control  cards  that 
invoke  the  desired  analyses.  The  allowable  syntax  for  these  cards  is  des¬ 
cribed  in  detail  in  the  HOS  Users'  Suide  and  on  the  HOS  Reference  Card. 
However,  unless  special  constraints  are  to  be  placed  on  the  analyses,  the 
following  control  cards  can  be  used  to  obtain  each  of  the  major  HODAC 
analyses: 


LABELS . 

DEVICES  BY  PARTS. 
DEVICES  BY  USAGE. 
DEVICES  BY  PROCEDURE. 
PROCEDURES. 


A  Timeline  Analysis  can  be  obtained  by  simply  inserting  the 

clause: 


TIMELINE  EVERY  n  SECONDS 

prior  to  the  period  on  any  of  the  preceding  control  cards,  where  n  is 
replaced  by  the  "snapshot"  interval. 

A  Channel  Loading  Report  can  be  obtained  by  inserting  a  clause: 

CHANNEL -LOADING  EVERY  n  SECONDS 

prior  to  the  period  on  any  of  the  preceding  control  cards,  where  n  is 
replaced  by  the  "snapshot"  interval.  (The  Timeline  clause  and  the  Channel 
Loading  clause  cannot  be  used  together.) 
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A  Link  Analysis  requires  the  definition  of  the  groups  to  be 
linked  together  in  the  analysis.  The  format  for  invoking  a  Link  Analysis 
is: 


LINKS  SYSTEM  system-name  =  device  THRU  device;  device 
SYSTEM  system-name  =  device  THRU  device. 

where  system-name  is  an  arbitrary  (and  optional)  name  supplied  by  the  user 
and  the  device  names  are  the  names  of  the  specific  displays,  controls,  and/or 
symbols  that  are  to  be  considered  members  of  a  group. 

4.8  UTILITIES 

Several  utilities  are  available  that  provide  listings  for  each 
of  the  HOS  programs.  These  utilities  —  LISTHAL,  LISTHOS,  and  LISTHOD  -- 
require  no  inputs. 
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APPENDIX  A 

THE  HOS  OPERATOR  MODELS 


A.l  COMPONENT  MODELS  USED  IN  HOS 

The  Human  Operator  Simulator  is  actually  a  set  of  models  for 
a  variety  of  components  of  human  performance  that  have  been  integrated 
tnto  a  general  composite  model  of  the  human  operator.  The  HOS  user  must 
provide  a  precise  description  of  the  operator's  task  and  the  equipment 
that  he  must  use  to  perform  the  task,  together  with  specifications  for 
several  parameters  relating  to  the  operator's  physical  and  performance 
characteristics.  HOS  then  applies  the  various  performance  models  to  the 
user's  input  in  order  to  produce,  as  output,  a  detailed  description  of 
the  operator's  performance  in  time. 

The  models  embodied  in  HOS  can  be  classified  as  follows: 

•  Olsplay  and  control  taxonomy. 

•  Task  component  taxonomy. 

•  Procedure  multiplexing  model. 

e  Anatomy  movement  models. 

•  Visual  and  tactile  perception  models. 

•  Memory  model . 

t  Mental  computation  model . 

The  display  and  control  taxonomy  and  task  taxonomy  are  models  that 
influence  and  must  be  evaluated  separately  from  the  dynamic  performance 
models  for  which  they  structure  the  inputs  and  outputs.  The  procedure 
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multiplexing  model  is  the  protocol  by  which  the  simulated  operator  (a 
serial  processor)  schedules  the  execution  of  his  various  tasks  (procedures). 
These  three  models  have  a  rather  diffuse  impact  on  HOS  simulations  in 
that  it  is  extremely  difficult  to  evaluate  any  of  them  except  by  assessing 
the  adequacy  of  the  total  HOS  system.  These  models  and  how  they  evolved 
are  described  in  Sections  A.  2  through  A. 4. 

The  anatomy  movement  models  describe  the  functional  assignments 
of  body  parts  (e.g.,  which  hand  to  use  to  grasp  a  particular  contro)  and  the 
dynamic  response  characteristics  for  each  body  part.  A  discussion  of  these 
models  is  presented  in  Section  A. 5. 

Section  A. 6  presents  a  detailed  description  of  the  structure  of 
the  perception,  memory,  and  mental  computation  models.  These  are  the 
models  of  the  operator's  cognitive  processes  as  represented  in  HOS.  They 
describe  how  the  operator  functions  as  an  information  processor,  i.e.,  how 
he  obtains  estimates  for  the  values  of  the  displays  and  controls,  and  per¬ 
forms  mental  calculations  that  are  mathematical  and  logical  functions  of 
these  values. 

We  will  frequently  point  to  theoretical  and  empirical  support 
for  the  HOS  models  in  the  literature  of  human  performance  psychology.  How¬ 
ever,  it  should  be  remembered  that  these  models  have  been  developed  to 
serve  an  immediate  practical  purpose  --  to  develop  a  simulation  of  the 
human  operator  that  provides  an  economical  tool  for  determining  the  human 
performance  consequences  of  any  particular  man-machine  interface  design. 
Thus,  we  have  had  to  impose  practical  constraints  on  the  models  in  order 
not  to  overwhelm  the  information  processing  capacity  of  the  computer  and 
to  maintain  consistency  within  the  HOS  models.  The  main  differences  between 
the  HOS  models  and  the  models  in  the  psychological  literature  lie  in  the 
fact  that  we  have  developed  several  models  for  performance  for  which  we 
could  find  no  directly  relevant  published  studies.  For  example,  in  the 
development  of  the  procedure  multiplexing  model  and  the  mental  computation 


model,  introspection  and  intuition  have  guided  the  model  development.  Since 
it  was  anticipated  that  the  HOS  mdoels  would  be  improved  as  appropriate 
research  findings  became  available,  the  HOS  software  system  has  been 
designed  in  a  modular  form  to  allow  easy  modification  to  any  of  the  com¬ 
ponent  models. 

A.  2  THE  PC'/ ICE  TAXONOMY 

The  classification  of  devices  used  in  HOS  has  a  significant 
impact  on  all  of  the  other  HOS  models.  The  classes  of  devices,  as  defined 
in  HOS,  are  listed  and  described  in  Table  A-l.  This  taxonomy  places 
devices  in  different  classes  whenever  qualitatively  different  procedures 
on  the  part  of  the  operator  would  be  required  to  use  the  devices.  Within 
each  class,  differences  between  devices,  such  as  size,  location,  and  range 
of  possible  values,  are  specified  by  the  user  on  HOS  data  cards.  These 
data  are  used  when  a  specific  device  is  accessed  in  a  specific  situation. 

A. 3  THE  TASK-COMPONENT  TAXONOMY 

The  basic  units  of  work  in  which  HOS  describes  the  actions  of 
the  simulated  operator  comprise  a  normative  model  of  human  performance. 

Two  levels  In  the  human  performance  hierarchy  are  employed  in  HOS  —  the 
procedural  level  and  the  individual  action  level. 

HOS  procedures  can  vary  from  the  "macro-level,”  those  describing 
mission  objectives,  to  the  “micro-level,”  those  describing  detailed  actions. 
There  are  five  basic  procedural  actions.  They  are: 

(1)  Activate  a  procedure  --  Place  the  procedure  on  an  active 
procedure  list  from  which  it  will  be  chosen  for  execution 
by  the  multiplexor  when  its  criticality  exceeds  that  of 
all  other  procedures  on  the  list. 

(2)  Complete  a  procedure  —  Discontinue  execution  of  the  current 
procedure  until  the  specified  procedure  has  completed 
execution. 
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Table  A-l.  HOS  Device  Taxonomy 


DEVICE  CLASS 

DESCRIPTION 

Discrete  Displays 

Devices  which  present  information  to  the  operator  in  terms  of 
discrete  settings. 

Continuous  Displays 

Devices  which  present  information  to  the  operator  in  terms  of 
values  which  may  vary  continuously  along  a  single  dimensional  scale. 

Positional  Displays 

Devices  which  present  information  to  the  operator  in  terms  of 
ordered  pairs  of  numbers. 

Discrete  Controls 

Manipulate  devices  that  can  assume  only  discrete  settings. 

Continuous  Controls 

Manipulate  devices  that  can  assume  values  which  may  vary 
continuously  along  a  single  dimensional  scale. 

Positional  Controls 

Manipulate  devices  for  which  the  device  value  is  defined  as  the 
location  of  the  control  element. 

Symbols 

Figures  that  appear  on  CRT  displays  for  which  information  is 
conveyed  by  the  location  of  the  figure  on  the  screen  and  for  which 
there  may  be  a  variety  of  associated  attributes  (e.g.,  size,  color, 
type),  each  of  which  may  be  either  discrete  or  continuous  • 

» 

> 

v 
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i, 


1 


(3)  Perform  a  procedure  —  Place  the  procedure  on  the  active 
procedure  list  and  begin  execution  of  the  procedure  immediately; 
do  not  resume  execution  of  the  current  procedure  until  the 
specified  procedure  has  completed  execution. 

(4)  Monitor  a  device  —  Place  the  procedure  for  adjusting  the 
device  on  the  active  procedure  list  and  periodically  execute 
the  adjust  procedure  until  told  to  stop. 

(5)  End  a  procedure  —  Remove  the  procedure  (regardless  of 
type)  from  the  active  procedure  list. 

These  procedural  actions  have  direct  HOPROC  statement  counterparts, 
enabling  complex  procedural  descriptions  to  be  achieved  with  a  minimum  number 
of  statement  types. 

The  operator's  repertoire  of  actions  has  been  adapted  principally 
from  the  studies  of  work  movements  performed  by  time-and-motion  analysts 
(see,  for  example,  Karger  and  Bayha,  1966).  The  major  departure  from  the 
time-and-motion  study  taxonomy  lies  in  the  inclusion  in  HOS  of  a  work  unit 
for  the  process  of  mental  computation.  This  addition  was  necessary  in 
order  to  enable  HOS  to  model  the  range  of  decision-making  functions  that 
would  be  made  by  an  autonomous  operator.  The  complete  set  of  basic  actions 
consists  of  the  following: 

•  Reaching  and  grasping  a  device  with  a  hand  or  foot.* 


*At  present,  HOS  models  body  movements  at  the  level  of  individual 
hands,  feet,  eyes;  movements  of  fingers,  elbows,  or  knees  are  not  modeled. 
Thus,  some  difficulty  would  be  encountered  if  the  present  version  of  HOS 
were  used  to  simulate  the  fine-grained  details  of  the  operation  of  a  type¬ 
writer  keyboard.  However,  these  limitations  are  not  expected  to  be  signifi¬ 
cant  in  any  of  the  currently  anticipated  applications  for  HOS. 
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•  Looking  at  a  device  --  moving  the  visual  fixation  point 
to  the  device  location. 

•  Absorbing  information  from  a  display,  control,  or  symbol 
via  vision  or  touch. 

•  Manipulating  a  control. 

•  Attempting  to  recall  the  value  of  a  device  or  function. 

•  Performing  the  computation  of  an  operator  function. 

A. 4  THE  MULTIPLEXING  MODEL 

As  stated  previously,  the  operator,  (1)  can  place  procedures  on 
an  active  procedure  list,  (2)  may  or  may  not  execute  them  immediately,  and 
(3)  can  remove  them  when  completed  or  no  longer  needed.  The  multiplexing 
model  controls  this  selection  of  procedures  --  it  selects  the  procedure  to 
be  executed  whenever  a  procedure  is  completed  or  interrupted.  While  the 
HOS  operator  can  execute  only  one  procedure  at  a  time,  individual  actions 
can  occur  simultaneously  if  they  do  not  require  the  same  physical  resources; 
virtual  parallel  processing  can  be  achieved  through  rapid  switching  between 
procedures.  Procedural  selection  takes  into  account  the  type  of  procedures 
on  the  active  procedure  list  (regular,  enable,  adjust,  or  disable);  the 
initial  criticality  for  each  procedure  as  supplied  by  the  analyst;  the 
amount  of  time  elapsed  since  the  procedure  was  last  executed;  and,  for  pro¬ 
cedures  that  monitor  continuous  devices,  how  close  the  value  of  the  device 
is  to  its  desired  value.  The  multiplexing  algorithm  has  been  designed  to 
give  an  intuitively  reasonable  weight  to  each  of  these  factors. 

There  are  several  principles  according  to  which  the  multiplexor 
operates;  they  are: 

(1)  If  all  procedures  on  the  active  procedure  list  are  inter¬ 
rupted,  then  the  simulation  time  is  incremented  until  one 
of  the  procedures  is  no  longer  interrupted. 
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(2)  If  there  is  an  uninterrupted  enable  procedure  on  the  active 
procedure  list,  then  that  procedure  is  given  absolute  priority 
over  all  other  procedures. 

(3)  If  steps  1  and  2  have  not  selected  a  procedure,  then  an 
effective  criticality  is  computed  for  each  uninterrupted 
procedure  and  the  procedure  with  the  highest  effective 
criticality  is  selected.  The  effective  criticality,  ECRIT, 
is  defined  as: 


ECRIT  *  CRIT  *TMULT*ADMULT 


CRIT  —  is  the  initial  criticality  supplied  by  the  analyst. 

TMULT  —  is  a  function  of  the  time  elapsed  since  the  last 
execution  of  the  procedure. 


AQMULT  —  is  a  factor  that,  for  monitor  procedures,  measures 
how  close  the  estimated  value  of  the  monitored  device  is  to 
its  desired  value. 


(4)  The  function  currently  used  for  TMULT  is: 


TMULT  «  1  +  log1Q  (  1  ♦  t) 

where  t  is  elapsed  time  since  the  last  execution.  AOMULT 
equals  1  for  all  procedures  other  than  monitor  procedures, 
for  which: 


AOMULT  =*  1  + 


E  -  DESIRE 
UPPER  -  DESIRE 


where 

E  —  is  the  operator's  estimate  for  the  value  of  the  device 
linearly  extrapolated  to  the  present  time. 

DESIRE  --  Is  the  desired  value  of  the  device. 

UPPER  —  is  the  upper  limit  for  the  desired  value  of  the 
device. 


Top  priority  is  given  to  enable  procedures  since  they  are  always 
prerequisite  to  the  execution  of  some  other  procedure  and  generally  consume 
very  little  time.  Relative  priorities  for  other  procedures  can  be  established 
by  the  analyst  through  the  choices  of  initial  criticalities  for  the  procedures. 
Criticalities  can  also  be  reassigned  by  the  analyst  throughout  the  simulation. 
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The  functions  for  TMULT  and  ADMULT  were  chosen  so  that  neither 
factor  would  completely  dominate  the  other.  Since  adjust  procedures  are 
expected  to  keep  the  estimated  value  of  the  adjusted  device  within  the  pre¬ 
scribed  limits,  ADMULT  is  expected  to  vary  between  1  and  2.  Clearly,  when 
ADMULT  is  near  2  (i.e.,  when  the  estimated  value  of  the  device  is  near  one 
of  its  limits),  the  adjust  procedure  should  have  a  high  criticality. 
Accordingly,  TMULT  was  defined  so  that  its  range  would  be  comparable  to 
that  of  ADMULT  over  the  domain  of  elapsed  times  appropriate  to  HOS  pro¬ 
cedures.  Thus,  TMULT  =  2  when  the  elapsed  time  is  9  seconds  and  TMULT  =  3 
when  the  elapsed  time  is  99  seconds. 

In  choosing  initial  criticalities  for  procedures  or  in  modifying 
critical ities  during  a  simulation,  careful  attention  must  be  given  to  the 
interaction  between  the  initial  criticality  and  TMULT.  Ignoring,  for  the 
moment,  the  contribution  of  ADMULT,  the  initial  criticality  of  a  procedure 
can  be  interpreted  as  a  factor  that  determines  how  long  a  procedure  must 
wait  on  the  active  procedure  list  before  it  attains  the  same  effective 
criticality  as  another  procedure  which  has  either  just  been  added  to  the 
list  or  just  completed  a  portion  of  its  execution.  For  example,  if  pro¬ 
cedures  A  and  B  are  on  the  list  and  have  initial  criticalities  of  CA  and 
Cg,  respectively ,  with  CA  >  Cg,  the  procedure  A  will  be  executed  first. 
Whenever  procedure  A  is  completed  or  interrupted,  TMULTft  will  be  exactly  1, 
since  the  elapsed  time  since  execution  of  that  procedure  is  zero.  TMULTg, 
on  the  other  hand,  will  be  greater  than  1.  As  long  as  procedure  A  remains 
on  the  list,  procedure  B  will  have  to  wait  until  TMULTg.  Cg  >  TMULTg  •  CA 
before  it  will  be  executed.  Since  TMULTg  will  always  be  exactly  1,  the 
minimal  waiting  time  for  procedure  B  will  be  the  time  at  which  TMULTg  =  C^/Cg. 
Table  A-2  indicates  the  minimal  waiting  times  for  procedure  B  for  a  variety 
of  values  of  the  ratio  C^/Cg.  Note  that  when  there  are  more  than  two  pro¬ 
cedures  on  the  list,  the  comparison  standard  (procedure  A)  should  always 
be  the  procedure  with  the  highest  initial  criticality  since  that  procedure 
will  dominate. 
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A. 5  THE  ANATOMY  MOVEMENT  MODELS 

The  HOS  anatomy  movement  model  determines  which  body  part  will 
perform  each  specific  perceptual  and  manipulative  task  and  how  much  time  will 
be  consumed  by  the  movement  required  to  accomplish  each  task.  Also,  to 
maintain  versimil itude,  the  anatomy  movement  model  moves  a  body  part  to 
a  ''relaxed"  location  whenever  the  body  part  is  to  remain  inactive  for  a 
period  of  time  specifiable  by  the  analyst.  The  model  currently  describes 
eye,  hand,  and  foot  movements.  Each  hand  and  foot  movement  time  is  deter¬ 
mined  according  to  a  straight  line  path  between  the  current  location  and 
the  desired  location,  whether  or  not  the  crewstation  geometry  would  actually 
permit  such  a  movement.  All  movements  are  ballistic,  i.e.,  they  cannot  be 
altered  or  terminated  mid-course.  The  hand  and  foot  movement  precision 
required  varies  with  the  dimensions  of  the  device  to  which  they  are  being 
moved  and  is  thus  included  in  the  movement  time  calculation,  thereby 
compensating  for  any  fine  positioning  movements  that  may  be  necessary. 

A. 5.1  Body  Part  Selection 

The  determination  of  the  body  part  to  be  used  in  accompl ishing 
any  task  is  made  according  to  a  set  of  common-sense  principles  in  conjunction 
with  the  constraints  that  the  analyst  places  on  which  body  parts  can  read 
and  manipulate  each  display  and  control.  Devices  can  be  characterized 
such  that: 

•  Only  the  eyes  can  read  the  device;  manipulations  are  not 
possible. 

•  The  eyes  are  preferred  for  reading,  but  the  hand  may  also 
be  used.  Hands  are  used  to  manipulate,  but  the  simulation 
will  require  the  operator  to  look  at  the  device  before  moving 
his  hand  to  it. 

•  The  hands  are  used  for  both  reading  and  manipulating  and  the 
operator  will  not  look  at  the  device  before  moving  his  hand 
to  it. 

•  The  feet  are  used  both  to  read  and  to  manipulate  the  device. 
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Sody  movements  are  initiated  by  either  an  explicit  instruction 
to  read  or  manipulate  a  device  or  by  an  instruction  to  look  at  or  grasp  a 
device.  The  logic  that  determines  which  body  part  will  be  used  is  somewhat 
different  for  these  two  situations.  The  SRASP/100K  AT  instruction  enables 
the  analyst  to  direct  the  operator  to  move  a  body  part  to  a  device  in 
anticipation  of  the  fact  that  he  will  later  have  to  read  or  manipulate  the 
device.  Consequently,  the  location  of  the  device  becomes  the  "grasp  location," 
i.e.,  the  location  at  which  the  assigned  body  part  is  to  be  kept  when  not 
needed  elsewhere,  until  some  action  (reading  or  manipulating)  is  performed 
by  that  body  part  at  that  location  or  until  another  "grasp  location”  is 
established  for  the  body  part.  If  the  body  part  is  moved  away  from  its 
"grasp  location”  in  order  to  read  or  manipulate  another  device,  it  will  be 
moved  back  to  the  "grasp  location”  as  soon  as  the  other  action  is  completed. 

When  the  instruction  is  to  "look  at”  a  device,  there  is,  of  course, 
no  difficulty  in  determining  the  appropriate  body  part  for  the  task.  How¬ 
ever,  when  the  device  is  to  be  grasped  by  a  hand,  HOS  must  decide  whether 
to  use  the  right  or  left  hand.  Figure  A-l  illustrates  the  logic  used  in 
making  that  decision.  If  the  hand  closest  to  the  device  has  no  assigned 
grasp  location,  then  that  hand  is  used.  Otherwise,  HOS  attempts  to  maintain 
any  old  grasp  locations,  if  possible,  by  using  the  less  preferred  hand  or 
by  switching  task  assignments  for  the  two  hands.  Grasp  locations  for  the 
feet  are  determined  according  to  exactly  the  same  logic  as  the  hands  with 
the  exception  that  the  foot  assignments  will  not  be  swapped  to  maintain 
an  old  grasp  location. 

The  logic  for  determining  which  hand  will  perform  a  reading  or 
manipulating  task  is  illustrated  in  Figure  A-2.  The  variable  TTNC  is  a 
user-specified  time  value  which  represents  the  maximum  amount  of  time  that 
the  simulated  operator  will  wait  for  an  occupied  body  part  to  become  avail¬ 
able  before  he  will  attempt  to  find  another  means  for  completing  a  task. 

If  the  hand  closest  to  the  device  of  interest  is  available  now  or  will  be 
available  within  TINC  seconds,  then  that  hand  will  be  used  for  the  action. 
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Figure  A-l.  Logic  of  Grasp  Location  Assignments 
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Figure  A-2.  Logic  of  Reading/Manipulating  Body  Part 

Assignments 
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Otherwise,  the  other  hand  will  be  used  if  it  can  reach  the  device  and  is 
available.  If  the  other  hand  cannot  reach  the  device  but  can  take  over 
the  task  which  the  preferred  (closest)  hand  is  performing,  then  the  hand 
assignments  are  swapped.  If  none  of  these  conditions  is  satisfied,  then 
the  operator  is  stymied  and  unable  to  continue  work  on  the  current  procedure 
until  the  situation  changes. 

The  logic  for  determining  the  assignment  of  feet  for  reading  and 
manipulating  is  exactly  the  same  as  for  hands,  except  that  foot  swapping  is 
not  allowed.  For  devices  that  can  be  read  by  either  the  eyes  or  the  hands, 
the  eyes  will  always  be  used  unless  a  hand  is  already  in  contact  with  the 
device. 

A. 5. 2  Movement-Time  Models 

The  times  associated  with  each  body  movement  are  based  on  formulas 
derived  from  a  variety  of  human  performance  studies.  These  equations  pre¬ 
dict  movement  times  that  are  based  solely  on  the  magnitude  of  a  movement; 
thus,  there  is  no  variability  as  is  observed  in  actual  human  performance  — 
the  current  equations  do  not  attempt  to  model  individual  differences  or 
random  variations  in  movement  times.  Thus,  at  present,  the  equations  describe 
a  perfectly  consistent  average  operator. 

Eye  movement  times  are  determined  as  a  function  of  the  changes 
in  angles  of  focus  and  onvergence,  as  shown  in  Figure  A-3.  The  change  in  the 
angle  focus,  as  shown  in  Figure  A-3a,  is  the  angle  between  the  two  fixation 
points  and  the  design  eye  reference  point.  If  the  vectors  from  the  design 
eye  reference  point  to  the  two  fixation  points  are  P.|  and  P^,  then  by  the 
law  of  cosines,  the  change  in  angle  of  focus  will  be; 
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FIXATION  POINT  1 
FIXATION  POINT  2 
ANGLE  OF  FOCUS  FOR  P, 
ANGLE  OF  FOCUS  FOR  P2 
CHANGE  IN  ANGLE  OF  FOCUS 


,-.(54) 


V  / 


P,  -  FIXATION  POINT  1 
P,  *  FIXATION  POINT  2 
^  -  ANGLE  OF  CONVERGENCE  FOR  P, 

«2  «  ANGLE  OF  CONVERGENCE  FOR  P2 

A*  •  CHANGE  IN  ANGLE  OF  CONVERGENCE  -  I  -<*2I 


Figure  A-3.  Derivation  of  Eye  Movement  Equations 
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where  P-j  •  P^  denotes  the  dot  product  of  P^  and  P^,  and  |  P-j  |  and  |P2| 
are  the  magnitudes  of  P^  and  P^,  respectively.  The  change  in  the  angle 
of  convergence,  as  shown  in  Figure  A-3b,  is  calcualted  by  assuming  that 
fixation  points  are  in  the  sagittal  plane  of  the  operator.  Thus,  the  angle 
of  convergence  is  the  angle  that  the  line  of  sight  for  either  eye  makes 
with  the  line  connecting  the  two  eyes.  For  an  interpupillary  distance  of 

^  h 

2.55  inches  (corresponding  to  a  50  percentile  USAF  pilot),  the  change 
in  the  angle  of  convergence,  A<t>,  will  be: 


Eye  movement  angles,  A8  and  AO,  when  related  to  movement  times 
in  an  experiment  involving  lateral  eye  movements  (conducted  by  Dodge  and 
Cline,  1901)  and  an  unpublished  study  that  involved  both  lateral  and  con¬ 
vergence  movements  (R.J.  Wherry  and  A.  Bittner),  yield  the  formula: 

T  =  . 14324A  +  .0175 

where  A  =  max  (A6.A0)  +  .2  min  (A8,A<J>)  in  which  A9  and  AO  are  expressed 
in  radians  and  T,  the  movement  time,  is  in  seconds. 

It  should  be  noted  that  this  model,  while  accurately  representing 
the  experimental  results,  describes  only  ballistic  eye  movements  and  does 
not  consider  the  processes  of  visual  search,  accommodation,  adaptation, 
or  interpretation. 

The  equations  for  hand  and  foot  movement  times  are  derived  from 
adaptations  of  Fitts'  model  for  speed  and  accuracy  of  body  movements  (Fitts, 
1954;  Fitts  and  Peterson,  1964).  Fitts'  law,  derived  from  Shannon  and 
Weaver's  theory  of  information  transmission  (Shannon  and  Weaver,  1949), 
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states  that  movement  time  is  a  linear  function  of  the  "information  content" 
of  a  movement.  The  Information  measure,  which  Fitts  called  an  index  of 
difficulty  (10)  is  defined  as: 

10  «  log2 

where  A  is  the  amplitude  of  the  movement  and  W  is  the  permissible  range  of 
terminal  movement  error  or  target  bandwidth.  The  validity  of  this  law  has 
been  demonstrated  for  a  variety  of  self-paced,  repetitive  movements  between 
two  targets  (Fitts,  1954)  and  for  discrete  movements  under  a  variety  of 
uncertainty  conditions  (Fitts  and  Peterson,  1964).  Other  investigators  have 
suggested  a  modification  of  the  definition  of  ID  which  provides  a  slight 
Improvement  in  the  descriptive  accuracy  of  the  law  (Wei ford,  1960;  Drury, 
1975).  The  revised  index  of  difficulty  (ID1),  which  was  designed  chiefly 
to  predict  movement  times  near  zero  for  ID  values  near  zero,  is  defined  as: 

ID1  -  log,  ^  £  *  .  s 

It  has  also  been  suggested  that  the  model  parameter  for  control  size,  W,  be 
interpreted  as  an  empirical  measure  of  movement  accuracy  rather  than  as  a 
directly  observable  dimension  of  a  device  (Crossman,  1960;  Welford,  1960; 
Orury,  1975).  Thus,  the  value  for  W  should  reflect  the  dimensions  of  the 
hand  or  foot  that  operates  a  control  and  the  manner  in  which  the  control 
is  contacted  (thumb  and  index  finger  grasp,  index  finger  depression,  etc.) 
as  well  as  the  size  of  the  device. 

Despite  the  widespread  acceptance  in  the  human  performance 
literature  of  some  version  of  Fitts'  law,  a  re-analysis  of  the  data  shows 
that  a  superior  funcitonal  description  is  possible.  Fitts'  law  Implies 
that  movement-time  can  be  decomposed  into  two  components,  one  of  which  is 
a  function  of  the  amplitude  of  the  movement,  the  other  a  function  of  the 
accuracy  of  the  movement  (i.e.,  the  width  of  the  target),  and  that  the 
total  movement  time  is  just  the  sum  of  these  two  component  times. 
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It  can  be  shown  that  the  best  decomposition  of  the  total  movement  times 
into  two  additive  components  (i.e.,  the  decomposition  that  minimizes  summed 
squared  error)  consists  of  assigning  the  marginal  means  plus  an  arbitrary 
constant  to  the  level  of  one  of  the  components  and  then  assigning  to  each 
level  of  the  other  component  the  mean  (for  that  level)  of  the  remaining 
movement  times.  Thus,  it  is  possible,  objectively,  to  separate  the  total 
movement  times  obtained  by  Fitts  into  two  components,  which  we  will  call 
travel  time  and  aiming  time,  without  making  any  assumptions  other  than 
that  the  components  are  additive.  The  decomposition  is  unique  only  up  to 
an  arbitrary  additive  constant,  although  the  restriction  that  the  component 
times  must  be  positive  severely  limits  the  allowable  range  for  the  constant. 

In  any  case,  the  shapes  of  the  empirical  functions  relating  travel  time  to 
distance  moved  and  aiming  time  to  target  size  are  uniquely  determined  by 
the  data.  We  have  decomposed  Fitts'  movement  time  data  in  this  manner  to  obtain 
travel  time  and  aiming  time  components  and  then  examined  each  of  the  com¬ 
ponents  separately  to  determine  what  mathematical  function  would  best 
relate  the  component  time  to  the  distance  moved  or  target  size.  This 
stragegy  avoids  the  assumption  inherent  in  Fitts'  approach,  that  v.h 
components  must  be  described  by  particular  logarithmic  functions.  In  fact, 
a  logarithmic  function  does  provide  a  very  good  fit  to  the  obtained  aiming 
time  data  for  which  we  found 

t^  =  .135  -  .096  1 og2  W 

where  tA  is  the  aiming  time  and  W  is  the  target  width.  The  travel  time 
data,  however,  appears  to  be  much  too  linear  to  permit  an  acceptable  fit 
by  a  logarithmic  function.  The  travel  time  function  is  clearly  negatively 
accelerated,  so  even  though  a  straight  line  fits  the  data  better  than  any 
logarithmic  function,  the  linear  function  is  also  unacceptable.  Figures 
A-4a  and  A-4b  display  the  empirical  functions  for  travel  time  and  aiming 
time  along  with  the  best  fitting  logarithmic  function  for  Fitts'  one  ounce 
stylus  data. 


Decomposed  lravel  and  Aiming  Time  Functions  for  Fitts' 
One  Ounce  Stylus  Reciprocal  Tapping  Data 


Although  HOS  requires  a  model  for  discrete  movements,  the  previous 
analysis  was  based  on  data  obtained  for  repetitive  movements  because  of 
the  lack  of  available  appropriate  data  for  discrete  movements.  Although  Fitts 
and  Peterson  (1964)  performed  the  appropriate  experiments  with  discrete 
movements,  they  report  their  movement  time  data  only  as  u  function  of  ID 
value  rather  than  reporting  separate  times  for  each  combination  of  target 
size  and  movement  distance.  The  best  linear  fit  between  ID  value  and 
movement  time  for  their  data  is: 

MT  =  .074  ID  -  .070 

where  MT  is  total  movement  time  in  seconds.  Since  Fitts  and  Peterson  report 
the  same  pattern  of  results  for  discrete  movements,  as  was  previously 
obtained  for  repetitive  movements,  it  seems  reasonable  to  assume  that  the 
aiming  time  components  of  this  function  would  be  acceptable,  while  the 
travel  time  component  would  be  better  described  by  some  other  function. 

Thus,  the  model  for  aiming  time  currently  used  in  HOS  is: 

0  for  w  >  Z 

.074  -  .  074  1 o g ^  W  for  0  <  w  s  2 


where  the  additive  constant  was  chosen  to  predict  zero  aiming  time  for  a 
two-inch  target.  The  cutoff  of  two  inches  for  target  width  was  employed 
because  the  available  data  did  not  include  any  larger  targets  and  because 
the  aiming  time  curve  appeared  fairly  level  at  that  point.  We  have  examined 
a  variety  of  functional  descriptions  for  travel  time,  but  the  available 
data  has  not  permitted  a  definite  choice  to  be  made.  Although  HOS  currently 
employs  a  travel  time  model  (suggested  by  Topmiller  and  Sharp,  1965),  we 
anticipate  modifying  this  model  in  the  near  future.  The  relationship 
proposed  by  Topmiller  and  Sharp  is: 


t 


T 
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where  tj  is  travel  time  and  d  is  distance  in  inches.  This  model  is  favored 
over  Fitts1  model  for  travel  times  because  it  was  derived  by  fitting  a 
curve  to  movement  times  obtained  for  movements  to  contro1  switches  on  a 
simulated  control  panel.  This  situation  is  deemed  much  more  relevant  for 
HOS  applications  than  are  the  movements  of  a  stylus  to  rectangular  targets, 
as  studied  by  Fitts  and  Peterson. 

It  has  recently  been  demonstrated  (Drury.  1975)  that  Fitts'  law 
applies  quite  well  for  repetitive  foot  movements  between  coplanar  pedals. 
For  this  situation,  Drury  found  that  the  best  linear  function  for  relating 
fU  to  ID1  was: 


MT 

repetitive 


.187  +  .085  ID1 


where  ID1  is  as  defined  previously  and  the  effective  pedal  width,  W,  is 
defined  as  the  sum  of  the  physical  pedal  width  and  the  operator's  shoe  width. 
This  formula  can  be  converted  to  a  formula  for  discrete  movements,  Drury 
argues,  by  multiplying  by  the  factor  relating  repetitive  hand  movement 
times  to  discrete  hand  movement  times  for  the  Fitts  studies.  (He  reports 
that  factor  as  '^iscretg/^Vepetitive  3  ,61)*  0rury's  formula  for  dis¬ 
crete  movements  between  coplanar  pedals  is,  therefore: 


^discrete 


.114  +  .053  ID1 


Limited  experiments  by  Davies  and  Watts  (1969),  in  which  discrete 
movements  between  coplanar  pedals  at  a  single  separation  were  compared  with 
movements  between  a  single  pair  of  non-cop! anar  pedals  suggest  that  this 
formula  can  ge  generalized  to  non-coplanar  pedals.  Their  results  showed  that 
it  took  an  average  of  .149  seconds  to  move  6.5  inches  between  coplanar 
pedals  and  .309  seconds  to  move  between  the  pedals  when  one  pedal  was  raised 
6  inches.  Assuming  that  the  time  penalty  for  non-coplanar  movements  over 
coplanar  movements  is  proportional  to  the  ratio  of  the  required  change  in 
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leg  extension  to  the  amplitude  of  the  movement,  movement  time  would  be 
predicted  by  the  general  formula: 


MT 


+  1.4 


.114  + 


.052 


seconds 


where  iE  is  the  change  in  leg  extension  required  by  the  movement.  We 
expect  that  this  model  will  be  modified  as  additional  relevant  data  become 
available.  For  the  present,  it  accurately  predicts  foot  movement  times 
between  pedals  of  common  dimensions  at  some  common  separations  consonant 
with  the  data  of  Oavies  and  Watts  (1969)  and  Drury  (1975). 

Times  associated  with  manipulating  controls  are  largely  left 
to  the  user  since  general  formulas  that  predict  manipulation  times  for  the 
diverse  types  of  contemporary  controls  are  not  available.  For  discrete 
controls,  HOS  requires  that  the  user  specify  the  time  that  it  takes  the 
operator  to  move  the  control  between  two  adjacent  settings.  The  time  con¬ 
sumed  by  a  manipulation  of  more  than  one  setting  is  then  calculated  as  the 
product  of  the  number  of  settings  to  be  moved  through  and  the  input  time 
cost  for  a  single  setting  cha  ,e.  In  assigning  the  input  time  costs  for 
discrete  devices,  it  is  thus  incumbent  on  the  user  to  determine  the  most 
salient  factors  that  characterize  each  control  to  be  modeled  and  then  to 
consult  a  reliable  source  in  order  to  obtain  empirical  manipulation  time 
data  for  that  type  of  control.  For  general  information  on  the  importance 
of  the  various  control  design  factors,  we  refer  the  reader  to  Chapanis  and 
Kinkade  (1972).  For  more  detailed  information  about  the  operation  of  key¬ 
set  devices,  we  suggest  that  the  reader  consult  Seibel  (1972).  A  variety 
of  sources  offer  experimental  data,  obtained  by  several  different  methods, 
on  the  times  for  operating  discrete  devices  --  Bradley  and  Wallis  (1959, 
1960),  Dean,  Farrel ,  and  Hitt  (1969),  Goldbeck  and  Charlet  (1974),  and 
MacPherson  and  Siegel  (1967). 
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An  explicit  formula  for  the  operation  of  continuous  rotary  con¬ 
trols  is  included  in  HOS,  requiring  only  that  the  user  specify  the  force 
needed  to  turn  the  dial.  This  formula,  derived  by  fitting  a  simple  quadratic 
function  to  a  table  of  idealized  data  (presented  by  Karger  and  Bayha,  1966), 
is: 


T  =  .0482  +  . 0050F  +  .Q825A  +  .0084  FA 

where  F  is  the  force  in  pounds  needed  to  turn  the  dial  and  A  is  the  angle 
through  which  the  dial  is  to  be  turned  in  radians.  Unfortunately,  we  have 
not  found  any  data  that  can  be  used  to  assess  the  validity  of  this  formula. 
However,  through  the  study  of  video-tape  records  of  control  operations  in 
the  course  of  a  protracted  mission,  Goldbeck  and  Charlet  (1974)  determined 
that  the  mean  time  that  the  operator’s  hand  stayed  in  contact  with  any 
continuous  rotary  control  on  a  single  manipulation  was  .73  seconds.  Of 
course,  this  time  may  include  some  Idle  dwell  time  as  well  as  multiple 
manipulations  that  were  not  discriminated  during  data  analysis.  Assuming 
that  the  forces  required  to  turn  the  knobs  in  that  study  were  about  one 
pound  and  the  magnitudes  of  the  turns  were  of  the  order  of  60°  to  120° 
(roughly  one  to  two  radians),  then  the  HOS  model  would  predict  manipulation 
times  in  the  vicinity  of  .2  seconds.  This  comparison  suggests  that  HOS 
may  underestimate  control  manipulation  times,  but  revising  the  model  would 
not  be  appropriate  until  sufficiently  comprehensive  data  (including  complete 
physical  specifications  of  the  controls)  becomes  available. 

A. 6  THE  COGNITIVE  M00ELS 

The  information  processing  functions  modeled  in  HOS  include 
infomation  absorption,  memory,  and  mental  computation.  The  models  for 
these  three  operations  are  intricately  interrelated  through  a.  variable 
termed  hab  strength  that  is  associated  with  each  device  or  mental  calcula¬ 
tion  and  represents  the  durability  or  strength  of  the  operator's  knowledge 
of  its  value.  The  models  are  also  related  to  one  another  by  informational 
task  demands  as  depicted  in  the  flowchart  of  Figure  A-5.  The  information 
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processing  models  may  be  accessed  either  directly  by  instruction  (as 
indicated  by  the  double  arrow  at  the  top  of  the  figure)  or  indirectly  by 
the  requirements  of  another  process,  such  as  when  the  computation  of  an 
operator  function  (the  HQS  term  for  mental  calculation)  depends  on  the 
absorption  (the  HOS  term  for  perception)  of  the  value  of  a  display  or 
control . 


In  examining  the  HOS  cognitive  models,  it  is  appropriate  to 
analyze  the  implications  of  each  of  the  following  considerations  for 
each  model: 

(1)  Type  of  information  to  be  handled. 

(2)  Aspects  of  performance  to  be  described. 

(3)  Specifications  of  processing  details. 

(4)  Interpretation  and  estimation  of  model  parameters. 

(5)  Experimental  situations  appropriate  for  model  verification. 

Each  point,  except  the  first,  will  be  treated  separately  for 
each  of  the  three  models  with  which  we  are  concerned.  Since  the  informa¬ 
tion  to  be  handled  by  the  models  is  essentially  the  same  for  all,  the  first 
point  will  be  discussed  only  once.  Also,  since  the  hab  strength  concept 
is  basic  to  all  three  models,  we  will  present  a  description  of  how  hab  is 
used  and  modified  by  the  models  before  we  discuss  the  specific  models. 

A. 5.1  Types  of  Information 

Oevice  values  are  represented  in  HOS  as  discrete  settings,  real 
numbers,  and  ordered  pairs  of  real  numbers  for  devices  that  are  declared 
as  discrete,  continuous,  and  positional,  respectively.  Each  such  value  is 
treated  as  a  single  item  or  "chunk"  although  the  range  of  possible  values 
may  vary  considerably  across  devices.  Values  of  operator  functions  are 
less  restricted  in  principle  than  are  device  values.  However,  function 
calculations  will  generally  represent  operations  performed  on  device  values 
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and  results  of  function  calculations  will  frequently  be  compared  with 
device  values;  thus,  function  values  can  also  be  assumed  to  represent 
either  discrete  settings,  real  values  on  continuous  scales,  or  positional 
quantities  (ordered  pairs  of  real  numbers). 

HOS  actually  maintains  several  parameter  values  that  relate  to 
the  operator's  knowledge  of  a  device  or  operator  function  value,  although 
only  one  represents  the  operator's  conscious  knowledge  of  the  current 
value.  In  particular,  the  information  stored  by  HOS  includes; 

•  The  actual  value  of  a  device  or  function. 

•  The  operator's  current  estimate  for  the  value  of  a  device 

or  function,  the  time  when  that  estimate  was  obtained,  and 
the  hab  strength  associated  with  that  estimate. 

•  The  estimated  value  that  the  operator  obtained  immediately 
prior  to  his  current  estimate,  the  time  when  that  prior 
estimate  was  obtained,  and  its  associated  hab  strength. 

•  The  desired  value  for  a  device  or  function. 

•  The  desired  upper  and  lower  limits  for  continuous  devices. 

Of  these  values,  only  the  current  estimated  value  is  obtained 
directly  by  the  absorption,  recall,  and  mental  computation  models.  The 
others  (except  for  the  desired  value  and  desired  limits  which  are  not 
used  by  the  cognitive  models)  are  used  only  in  defining  the  functional  forms 
of  the  models  and  do  not  represent  values  of  which  the  operator  is  consciously 
aware. 


All  information  that  is  absorbed,  recalled,  or  computed  by  the 
simulated  operator  is  limited  to  the  categories  of  discrete  settings,  real 
numbers,  and  ordered  pairs  of  real  numbers.  The  operator  does  not  have  to 
recall  the  steps  in  the  procedures,  and  differences  between  two  displayed 
values  are  not  perceived  directly  through  the  absorption  model.  However, 
the  HOS  user  has  considerable  freedom  in  defining  what  is  to  be  considered 
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a  display  or  control,  and  operator  functions  may  be  constructed  that  perform 
functions  other  than  simple  numerical  calculations.  For  example,  a  clock 
wth  an  hour  hand  and  a  minute  hand  may  be  treated  as  a  single  display  for 
time  or  it  may  be  treated  as  two  distinct  displays  sharing  the  same  scale, 
one  indicating  hours  and  the  other  minutes.  These  two  ways  of  describing 
the  display  might  actually  correspond  to  two  different  display  reading 
strategies  available  to  the  operator  —  alternate  ways  of  "chunking11 
information.  The  consideration  of  how  information  is  "chunked"  will  be 
relevant  to  the  evaluation  of  all  three  cognitive  models. 

-  A.6.2  Hab  Strength  Modification 

The  concept  of  hab  strength  underlies  all  of  the  HOS  models  for 
cognitive  functions.  It  determines  whether  or  not  recall  attempts  will 
succeed  and  how  much  time  will  be  consumed  by  the  processes  of  recall, 
perception,  and  mental  calculation.  Like  its  namesake  in  the  elaborate 
stimulus-response  ($-R)  learning  theory  of  Clark  Hull,  it  represents  a 
measure  of  how  well  something  is  learned.  However,  unlike  the  Hullian 
concept  of  hab  strength,  which  indicates  the  relative  intensity  with  which 
a  particular  stimulus  tends  to  evoke  a  particular  response,  the  HOS  concept 
of  hab  strength  indexes  the  durability  of  an  item  of  information  in  a 
temporary  memory  store. 

The  hab  strength  for  an  item  is  modified  when  an  estimated  value 
is  obtained  by  absorption  or  computation  or  when  the  value  is  successfully 
recalled  from  memory;  the  same  formula  is  used  to  compute  a  new  hab  strength 
whenever  any  of  these  events  occur.  The  hab  strength  is  modified  once 
upon  the  completion  of  the  recall  process;  for  the  absorption  and  computation 
processes,  it  is  modified  once  for  each  "micro-absorption"  process  or  "micro- 
computation."  The  new  hab  strength  is  observed  from  the  old  by  the  formula: 


H 


1 


V  *  (1-V) 


S 

1  *  (t-R) 


(1) 
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where 


R 

k 

t 

S 

V 


is  the  new  hab  strength, 
is  the  old  hab  strength. 

is  an  input  constant  (REMEM)  representing  the  memory, 
cycle  time 

is  an  input  constant  (HABFAC)  used  as  a  scale  factor. 

is  the  time  since  the  estimated  value  was  last  determined. 

is  a  measure  of  the  similarity  between  the  current  and 
previous  estimated  values  of  an  item. 

is  a  base  level  for  the  hab  strength  of  that  item. 


The  measure  of  similarity  between  two  estimated  values,  S,  ranges 
between  0.1  and  1.0.  For  discrete  devices,  S  is  always  1.0,  For  continuous 
devices  and  functions,  S  is  defined  by  the  formula: 


S 


1.0 

e- [  CA-D/61  2 
0.1 


if  A  <  1  • 

if  1  <  A  <  10.105 

if  A  >  10.105 


where 


A 


E-PE 

TOL 


E  3  current  estimated  value. 


PE  =  previous  estimated  value. 


TOL  =  user-supplied  parameter  representing  a  desired  accuracy 
tolerance  for  each  device. 
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The  minimum  value  of  the  hab  strength  for  a  device  or  function, 

V,  is  a  constant  between  0.1  and  1.0  for  that  device  or  function.  V  may 
be  interpreted  as  the  minimum  hab  strength  that  would  be  assigned  if  S  were 
zero  (though  S  can  actually  never  be  smaller  than  0.1).  Values  for  v  are 
dependent  upon  the  declared  character  of  each  device  and  function  as  follows 

V  *  0.1  for  discrete  devices  with  more  than  six 

possible  settings  and  all  functions  and 
continuous  or  positional  devices. 

V  a  —  -  .05  for  all  discrete  devices  for  which  the 

number  of  possible  settings,  n,  is  six  or 
1  ess . 

V  *  .95  for  all  momentary  devices 

These  values  can  be  loosely  interpreted  as  the  probabilities  of 
"guessing11  the  value  of  a  device,  i.e.,  the  minimum  hab  strength  is  higher 
for  devices  with  lower  inherent  uncertainty. 

Two  constraints  are  imposed  on  Equation  1  in  its  use  in  H0S  in 
order  to  maintain  hab  strength  in  the  interval  between  0.1  and  1.0.  First, 
if  Hg  is  less  than  or  equal  to  0.1,  then  HQ  is  set  to  0.1  and  t  is  set  to 
zero.  Secondly,  if  application  of  Equation  1  produces  a  value  of  greater 
than  1.0,  then  is  set  equal  to  1.0. 

In  discussing  the  implications  of  Equation  1,  it  will  be  useful 
to  rewrite  it  as: 

*  V  ( 1  -V)  .  H0  •  M  (2) 


where 


The  factor  M  then  represents  the  influence  of  the  previous  determination 
of  an  estimated  value  on  the  new  hab  strength.  In  order  to  ensure  that  M 
is  positive  and  finite,  k  must  be  chosen  so  that  ^  >  k  z  0.  That  is,  k 
must  be  chosen  to  be  non-negative  and  smaller  than  the  reciprocal  of  R. 
Then,  M  will  be  larger  than  S  whenever  t  is  less  than  R,  and  M  will  be 
smaller  than  S  when  t  exceeds  R. 

In  order  to  understand  the  HOS  models  for  absorption  and  function 
computation,  it  will  be  useful  to  describe  the  effects  of  repeated  applica¬ 
tions  of  Equation  2.  Such  a  description  is  only  feasible  if  M  reamins 
constant  for  successive  applications,  i.e.,  if  S  is  constant  and  either  t 
is  constant  or  k  is  zero.  In  many  interesting  siutations  in  HOS,  the 
factor  M  does  remain  constant  for  successive  applications  of  Equation  2. 

If  H.  denotes  the  hab  strength  after  the  jth  application  of  Equation  2  when 
the  starting  hab  strength  was  Hq,  then  it  can  be  shown  that: 

Hj  =  h  -  (l-v)j  MJ  (h  -  H0)  if  M  <  jiy  (3) 


where 


h  = 


1  -  (1-V)  M 


Note,  that  if  j  increases  without  bound,  the  H.  will  approach  h.  That  is, 

J 


H  =  lira  H. 

«  j 

1  -*co  J 


h  for  M  < 


1 

1-V 


(4) 
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H  is  thus  the  asymptotic  value  of  successive  applications  of  Equation  2 

30 

when  M  is  not  too  large.  We  can  use  Equation  4  to  rewrite  Equation  3  as: 

H.  -  Ha  -  (l-v)j  Mj  -  Hq)  for  M  <  fa  (S) 

wnich  incicates  how  each  successive  application  of  Equation  2  brings  the 
hab  strength  closer  to  H^. 

In  addition  to  knowing  the  asymptotic  value  for  hab  strength, 

ft  will  be  important  to  know  how  rapidly  this  value  is  approached  and, 

in  particular,  how  many  applications  of  Equation  2  will  be  required  in 

order  for  hab  strength  to  exceed  a  predetermined  value.  This  is  important 

because  in  the  HOS  models  for  absorption  and  computation,  micro-attempts 

at  absorption  or  computation  are  repeated  with  the  hab  strength  being 

incremented  according  to  Equation  2  on  every  micro-attempt  until  hab  strength 

exceeds  a  user-supplied  value.  This  value  represents  the  certainty  threshold 

that  the  operator  must  attain  before  he  is  "satisfied''  with  the  result.  We 

will  discuss  the  consequences  of  this  model  under  the  assumption  that  M  is 

constant  in  Equation  2,  by  using  Equation  3.  In  particular,  we  will  want 

to  know  how  many  micro-attempts  will  be  required  to  raise  a  hab  strength, 

Hq,  less  than  the  threshold  to  a  value  that  exceeds  the  threshold.  For 

this  to  be  a  meaningful  problem,  we  must  require  that  the  asymptotic  value 

for  hab  strength,  H^,  be  greater  than  the  threshold  since,  otherwise,  the 

hab  strength  will  never  exceed  the  threshold.  Letting  L  be  the  threshold 

and  the  hab  strength  after  the  kth  micro -attempt,  we  can  convert  Equation 

5  to  a  continuous  function  of  j  and  apply  a  logarithmic  transformation  to 

determine  the  number,  N.  ,  for  which  HN  <  L  <  H..  .  The  solution  is: 

L  \  L 
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where  Ig ( X )  is  the  "greater  integer"  function,  i.e.,  the  smallest  integer 
that  is  greater  than  or  equal  to  X. 

A  second  constraint  placed  on  the  growth  rate  of  is  based  on 
the  idea  that  if  the  increment  in  hab  strength  resulting  from  a  micro¬ 
attempt  is  too  small,  then  the  operator  should  stop  trying  to  absorb  or 
compute  a  value.  As  in  the  preceding  case,  we  are  interested  in  knowing 
how  many  micro-attempts  can  be  allowed  before  the  absorption  or  computation 
process  will  be  stopped  by  this  limit,  d.  Again,  if  we  assume  that  the 
same  value  of  M  applies  for  all  micro-attempts,  then  the  absorption  process 
will  be  terminated  at  the  iteration  where: 


In  d  -  In 

[l  -  (1-V)  m] 

-  In  1 

(IH.  -  H„|) 

In 

[(1-V)  Nl] 

-  +  1 


(7) 


Under  the  stated  assumptions,  the  preceding  derivations  for  H^, 

Nl,  and  represent  precise  determinations.  The  most  severe  restriction 
was  that  M  in  Equation  2  had  to  be  constant  for  successive  micro-attempts. 
Although  this  assumption  is  valid  for  many  absorption  and  function  computa¬ 
tions,  it  is  also  desirable  to  know  something  about  H^,  N^,  and  when  this 
is  not  the  case.  Since  M  depends  on  both  the  similarity  between  successive 
estimated  values  and  the  time  interval  separating  their  determinations,  if 
variations  in  similarity  and  time  separation  between  estimates  for  an  item 
are  reasonably  erratic,  then  M  can  be  treated  as  a  random  variable.  If  this 
is  the  case,  M  can  be  replaced  by  its  expected  value  in  Equations  4,  6,  and 
7,  and  the  formulas  will  represent  expected  operator  approximations  for  H^, 
and  N^,  respectively.*  However,  if  M  varies  systematically  across 


*See  3ush  and  Mosteller  (1956)  for  a  discussion  of  expected  operator 
approximations  for  learning  models  similar  to  Equation  2. 
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successive  applications  of  Equation  2,  then  the  values  for  N^,  and 
must  be  derived  in  accordance  with  the  specific  manner  in  which  M  varies. 

A. 6. 3  The  Function  Computation  Model 

Operator  functions  enable  HOS  to  model  the  processes  by  which 
the  operator  derives  values  from  directly  observed  information.  Thus,  they 
represent  the  arithmetic  and  logical  functions  that  are  carried  out  "in 
the  operator's  head."  In  addition,  operator  functions  enable  the  analyst 
to  access  all  the  global  FORTRAN  variables  in  HOS  and  thus  they  possess  all 
the  power  inherent  in  a  high-level  computer  language  like  FORTRAN.  As  a 
result,  they  can  be  used  for  other  purposes  than  to  simulate  the  psychologic¬ 
ally  plausible  operations  of  arithmetic  and  logic.  The  open-endedness  of 
operator  functions  poses  some  real  difficulties  when  we  attemot  to  interpret 
just  what  cognitive  operations  are  represented  by  any  specific  operator 
function.  Such  uses  of  operator  functions  need  not,  however,  compromise 
the  accuracy  of  HOS,  if  the  user  is  careful  to  assign  a  zero  time  cost  to 
any  operator  function  that  does  not  represent  a  cognitive  process  or  to 
assign  a  high  enough  time  cost  to  any  function  that  represents  more  than  a 
simple  mental  calculation. 

Because  of  the  diversity  of  mental  processes  that  can  be  simulated 
by  operator  functions,  the  analyst  must  define  each  operator  function  in 
FORTRAN  and  supply  a  basic  time  cost  for  each  function.  Whenever  the  value 
of  the  function  is  required  by  a  procedure  or  by  another  operator  function, 

HOS  will  either  attempt  to  remember  the  value  of  the  function,  or  will 
execute  the  appropriate  code.  The  time  associated  with  the  function  calcula¬ 
tion  will  be  the  sum  of  the  times  required  to  obtain  any  values  needed  by 
the  function  (e.g.,  values  of  devices  or  other  functions),  plus  the  basic  time 
cost  for  the  function  multiplied  by  the  number  of  times  the  hab  strength 
calculations  must  be  repeated  before  any  one  of  the  following  criteria  is 
sati s^ied. 
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•  Hab  strength  is  greater  than  or  equal  to  a  threshold 
"confidence"  level  (Equation  6  in  Section  A. 6. 2). 

•  Two  successive  determinations  of  the  hab  strength  differ 
by  less  than  a  user-specified  amount  (Equation  7  in 
Section  A. 6. 2). 

•  The  number  of  iterations  multiplied  by  the  basic  time 
cost  exceeds  a  user-specified  time  limit. 

•  The  number  of  iterations  exceeds  the  user-specified  limit. 

In  determining  the  time  costs  for  operator  functions,  the  user 
will  have  to  depend  mainly  on  his  own  ingenuity  and  resources  because  of 
the  sparsity  of  general  guidelines  and  experimental  data  in  the  published 
literature.  Whenever  possible,  it  is  advisable  to  conduct  at  least  an 
informal  experiment  to  determine  an  approximate  time  cost.  For  general 
theories  on  mental  arithmetic  and  some  relevant  experimental  data,  we  refer 
the  reader  to  Thomas  (1963),  Oansereau  and  Gregg  (1966),  and  Restle  (1970). 
Some  time-and-motion  study  data  on  mental  work  is  available  in  Quick,  Duncan, 
and  Malcolm  (1962). 

A. 6. 4  The  Absorption  Model 

The  HOS  model  of  perception  is  tailored  specifically  to  the  informa 
tion  processing  requirements  of  a  complex  man-machine  interface.  Whereas 
most  contemporary  theories  and  models  for  perception  attempt  to  describe  how 
sensory  signals  are  processed  into  higher  order  codes,  the  HOS  absorption 
model  is  concerned  only  with  the  changes  through  time  in  the  operator's 
knowledge  of  the  state  of  a  display  or  control.  It  is  therefore  best  to 
refer  to  it  as  an  absorption  model  rather  than  a  perception  model. 

The  same  model  is  used  to  describe  the  absorption  of  information 
both  by  vision  and  by  touch.  The  user  must  specify  which  modality  is 
appropriate  for  absorbing  from  each  device  and  whether  the  other  modality 
can  be  used  when  the  preferred  channel  is  otherwise  occupied.  The  user 
must  also  provide  HOS  with  a  single  parameter  value  for  each  device  that 
specifies  a  basic  time  cost  unit  for  absorptions  from  the  device. 
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Absorption  occurs  in  quantum  steps  called  micro-absorptions  that 
are  repeated  until  a  termi nation  criterion  is  satisfied.  Each  micro¬ 
absorption  consists  of  an  updating  of  the  estimated  value  and  the  hab 
strength  of  an  item  and  the  assessment  of  a  time  charge  for  the  micro¬ 
absorption.  The  micro-absorption  process  is  repeated  until  any  of  the 
following  four  termination  criteria  is  satisfied  (basically  the  same  as 
for  function  computations): 

(1)  Hab  strength  is  greater  than  or  equal  to  a  threshold 
"confidence"  level  (Equation  6  in  Section  A. 6. 2). 

(2)  Two  successive  determinations  of  the  hab  strength  differ 

by  less  than  a  user-specif ied  amount  (Equation  7  in  Section 
A.6.2). 

(3)  The  amount  of  time  spent  in  the  absorption  process  exceeds 
a  user-specified  time  limit. 

(4)  The  number  of  iterations  exceeds  the  user-specified  limit. 

This  process  is  illustrated  in  the  flowchart  in  Figure  A-6  in 
which  T  denotes  the  simulation  time,  C  is  the  micro-absorption  time  charge, 
and  H(k),  V,  R,  K,  d,  and  L  are  the  quantities  described  in  Section  A. 6. 2. 

The  details  of  these  updating  and  time  assessment  processes  are 
determined  by  whether  the  device  is  discrete,  continuous,  or  positional; 
accordingly,  we  will  analyze  each  case  separately. 

For  discrete  devices,  the  estimated  value  of  a  device  is  set  equal 
to  its  actual  value,  i.e.,  absorption  of  discrete  devices  is  error-free.  The 
hab  strength  for  discrete  devices  is  modified  according  to  the  general 
formula  described  in  Section  A. 6. 2,  with  the  similarity  between  the  last 
two  estimates  being  set  to  1.0.  The  time  charge  for  each  micro-absorption 
is  simply  the  basic  time  charge  associated  with  the  device. 


264 


Since  the  model  automatically  sets  the  estimated  value  equal  to 
the  actual  value  on  the  first  micro-absorption,  the  model  makes  no  attempt 
to  describe  the  relative  accuracy  of  the  absorptions  from  discrete  devices. 
Thus,  absorption  from  a  discrete  device  is  completely  deterministic. 

The  absorption  process  for  continuous  and  positional  devices  is 
similar  to  that  for  discrete  devices,  with  embellishments  appropriate  to 
the  fact  that  the  devices  are  continuous.  The  major  differences  are  that: 

(1)  On  each  micro-absorption  a  new  estimated  value  is  determined 
by  averaging  the  actual  value  with  a  value  extrapolated 
linearly  from  the  last  two  estimates. 

(2)  The  micro-absorption  process  is  not  allowed  to  terminate 
until  the  estimated  value  lies  within  a  user-prescribed 
range  around  the  actual  value  (the  "accuracy"  associated 
with  the  device). 

(3)  The  time  cost  for  each  micro-absorption  is  calculated  from 
the  basic  micro-absorption  time  charge  for  the  device  and 
the  "dissimilarity"  between  the  last  two  estimated  values. 

Absorptions  from  positional  devices  ( i . e. »  absorptions  of  ordered 
pairs  of  numbers)  are  treated  as  simultaneous  absorptions  of  the  two  numbers 
in  the  ordered  pair,  each  number  being  treated  as  a  continuous  value.  The 
time  charge  for  an  absorption  is  then  the  maximum  of  the  time  costs  for 
the  individual  components. 

It  is  difficult  to  derive  a  general  formula  for  the  time  cost 
of  an  absorotion  from  a  continuous  or  positional  device,  because  of  dif¬ 
ficulties  in  soeci^ying  the  time  cost  for  each  iteration  or  the  number  of 
iterations  that  will  be  required  to  bring  the  estimated  value  within  the 
specified  tolerance  range.  As  indicated  in  Figure  A-6,  the  time  cost  of 
each  iteration  cycle  is  (1  +  j  •  DS)C,  where 


is  a  measure  of  the  dissimilarity  between  the  two  most  recent  estimates  of 
the  device  and  E  and  PE  are  the  two  most  recent  estimates.  Note,  that  if 
! E-PE |  <  TOL,  then  DS  =  .5.  That  is,  if  the  two  most  recent  estimates 
differ  by  less  than  the  "accuracy,"  then  the  dissimilarity  value  is  exactly 
.5.  It  is  likely  that  this  condition  will  hold  for  most  absorption  pro¬ 
cesses,  at  least  after  the  first  iteration  cycle,  so  the  time  cost  for 
each  such  micro-absorption  will  be  exactly  1.25C.  Given  this  situation,  the 
recursion  formula  for  E(k+1),  reduces  to: 

E(k+1 )  =  . 5A  . 9E( k)  -  .4E(k-1) 

Two  sample  sequences  of  estimated  values  are  graphed  in  Figure  A-7; 
it  is  assumed  that  the  actual  value,  A,  is  constant  and  that  [ E ( 1 )  -  E(0)|  s  TOL. 
Observe  how  the  values  are  first  on  one  side  of  the  actual  value  and  then 
are  on  the  other  side.  Also,  note  that  the  speed  of  convergence  of  the 
sequence  does  not  differ  very  much  between  the  two  sequences  even  though 
the  two  initial  values  are  quite  different  in  the  two  cases.  We  have  studied 
many  such  sequences  of  estimated  values  generated  by  the  absorption  model 
in  order  to  determine  just  how  much  the  rate  of  convergence  actually  varies. 
Figure  A-8  displays  the  number  of  iterations  that  must  be  performed  for 
a  variety  of  initial  values  in  oHer  to  bring  the  estimated  value  within 
a  two  percent  tolerance  range  of  the  actual  value.  Although  other  tolerance 
values  will  generally  be  used  in  HOS,  it  is  interesting  to  note  that  con¬ 
vergence  to  this  fairly  strict  tolerance  is  rapid  and  varies  only  slightly 
between  even  the  most  disparate  choices  of  initial  values. 

A. 6. 5  The  ShO'-L-Term  Memory  Model 

he  HOS  operator  is  considered  to  be  a  "trained"  operator.  Thus, 
there  are  many  quantities  (e.g.,  knowledge  of  task  procedures  and  locations 
of  stationary  displays  and  controls)  that  are  considered  to  be  in  long-term 
memory,  i.e.,  the  operator’s  ability  to  recall  any  of  these  quantities  is 
unaffected  by  the  passage  of  time.  However,  most  of  the  display  and  control 
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Figure  A-7.  Convergence  of  Estimated  Valu 
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=  .5A  +  ,9E(k)  •  ,4E(k-1 ) 


Figure  A-8.  Number  of  Extrapolation  Iterations  Required  to 
Bring  Estimated  Value  Within  a  Two  Percent 
Tolerance  of  Actual  Value  (A)* 


*If  any  subsequent  iteration  falls  outside  two  percent  bounds,  super¬ 
script  indicates  first  iteration  such  that  no  subsequent  iterations  exceed 
tolerance. 
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values  vary  with  time.  These  items  are  normally  not  committed  to  long-term 
memory  and,  therefore,  the  HOS  process  of  retrieving  the  data  corresponds 
to  a  short-term  memory  model . 

The  variety  of  human  performance  characteristics  that  a  short-term 
memory  model  should  be  able  to  describe  and  that  have  been  addressed  by 
other  models  of  memory,  include: 


•  Probability  of  successful  recall. 

•  Time  cost  (or  latency)  or  recall. 

•  Probability  of  transfer  to  long-term  memory. 

•  Effects  of  interactions  between  items  in  short-term  store 
and  items  in  long-term  store. 

The  HOS  memory  model  has  been  designed  to  predict  only  the  prob¬ 
ability  of  recall  and  the  time  cost  associated  with  a  recall  attempt.  HOS 
considers  only  the  estimated  value  of  a  device  to  be  subject  to  decay  and 
forgetting  --  none  of  the  other  characteristics  of  a  device  enter  the 
recall  model  —  i.e.,  no  other  characteristics  of  a  device  can  be  forgotten. 
HOS  will,  at  the  option  of  the  user,  extrapolate  recalled  values  to  the  time 
at  which  the  recall  attempt  is  made  and/or  degrade  the  accuracy  of  recalled 
values  to  simulate  the  uncertainty  associated  with  the  recalled  value. 


The  HOS  memory  retrieval  model  is  based  on  data  obtained  in  several 
experimental  studies  of  short-term  memory,*  in  which  it  was  found  that  the 
relationship  between  probability  of  correct  recall  of  an  item  and  time 
since  presentation,  could  be  described  by: 


P 


(3) 


•Petersen  and  Peterson  (1959)  and  Murdock  (1961). 
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where 


P  =  the  probability  of  correct  recall. 

t  =  the  time  interval  between  presentation  and  attempted  recall. 

H  =  a  constant  in  the  unit  interval  characteristic  of  the  subject 
and  the  experimental  situation. 

The  H  in  Equation  3  is  the  formal  definition  of  hab  strength.  How¬ 
ever,  as  described  in  the  preceding  sections,  rather  than  being  a  constant, 

H  is  modified  by  HOS  whenever  a  device  or  function  is  estimated. 

Equation  8  was  found  to  hold  for  a  variety  of  experimental  situa¬ 
tions,  providing  that  the  subjects  are  prevented  from  rehearsing  the 
stimuli  during  the  period  between  presentation  and  recall.  Notice  that 
this  equation  implies  that  if  H  +  1,  P  must  approach  zero  as  t  becomes 
large,  so  that  the  processes  of  long-term  memory  and  random  guessing  are 
not  described. 

It  should  be  noted  that  the  function  usually  used  in  psychological 
literature  to  summarize  the  short-term  memory  data,  differs  slightly  from 
the  previous  equation.  The  function  is  generally  described  as  exponential 
(Pollatsek,  1969)  with  the  general  form: 


?  =  Ke*kt  (9) 

where  K  and  k  are  positive  constants.  Equation  8  differs  from  this  general 
form  only  in  that  the  exponent  is  S£ ~  rather  than  t.  This  particular  choice 
of  exponent  was  made  in  order  to  make  the  memory  model  produce  reasonable 
recall  probabilities  when  the  hab  strengths  were  generated  by  the  procedure 
described  in  Section  A. 6. 2.  A  comparison  of  Equations  3  and  9  with  the 
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experimental  data,  has  revealed  that  neither  function  produces  a  significantly 
better  fit  than  the  other. 

The  HOS  short-term  memory  model  is  actually  somewhat  more  com¬ 
plicated  than  Equation  8  would  Indicate.  This  equation  is  used  to  obtain 
the  probaoility  of  successful  recall  on  a  single  recall  attempt.  However, 
under  certain  conditions,  the  operator  can  make  more  than  one  recall  attempt 
and  tne  time  consumed  by  the  recall  process  depends  both  on  the  number  of 
attempts  and  on  whether  or  not  recall  succeeds.  In  addition,  the  model 
has  optional  mechanisms  for  degrading  the  precision  and  extrapolating  the 
values  of  continuous  devices  that  are  successfully  recalled. 

Figure  A-9  describes  the  complete  HOS  memory  model.  The  time 
consumed  by  an  attempt  to  recall  a  value  is  indicated  as  "Cost”  in  the 
figure.  Each  micro-attempt  at  recall  (i.e. ,  each  cycle  through  the  model) 
requires  a  constant  amount  of  time  and  if  recall  succeeds,  the  time  cost 
is  Incremented  one  additional  time  by  the  same  amount  ot  account  for  the 
time  spent  in  retrieving  the  preceding  value  (i.e.,  the  next  to  the  last 
value  which  is  needed  to  extrapolate  to  the  current  estimate).  The  short¬ 
term  memory  cycle  time,  R,  is  an  input  parameter  that  is  constant  for  each 
simulation  and  considered  to  be  a  characteristic  of  the  operator. 

If  a  micro-attempt  at  recall  fails  (i.e.,  if  X,  a  random  number 
drawn  from  a  uniform  distribution  on  the  unit  interval,  is  greater  than  P, 
the  probability  of  recall),  then  further  micro-attempts  may  or  may  not  be 
made,  depending  on  the  value  of  (X  -  P)/H.  If  this  value  is  less  than  or 
equal  to  a  user-specified  constant,  then  another  micro-attempt  will  be 
made.*  This  formalizes  the  intuitive  notion  that  the  operator  will  continue 
to  attempt  to  recall  a  value  if  the  current  recall  attempt  has  almost  succeeded. 


*If  limits  on  the  number  of  recall  attempts  and  the  amount  of  time 
spent  in  recall  have  not  been  exceeded. 
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Figure  A-9.  HOS  Short-Term  Memory  Model 
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Since  the  probability  of  repeated  micro-attempts  at  recall  is 
dependent  on  the  user-supplied  values,  the  possibility  of  getting  “stuck" 
in  a  perpetual  recall  loop  exists.  For  example,  if  the  hab  strength,  H, 
for  an  item  is  .5,  and  if  100  seconds  have  elapsed  since  a  value  was  last 
estimated  (i.e. ,  t  a  100),  then  the  probability  of  successful  recall  at  each 
micro-attempt  is  at  most 

p  -  H  n  .5  v'ToT  ,  >001 


If  the  value  of  d  were  2.0,  then  whenever  a  micro-attempt  failed 
(as  would  happen  more  than  99.9  percent  of  the  time),  another  micro-attempt 
would  always  be  allowed  since 


X-P 

H 


X-P 

TsJ 


s 


2.0 


which  must  be  true  because  0  <  X-P  <  1.0.  Thus,  although  there  would  be 
virtually  no  chance  of  recalling  the  value,  the  operator  would  never  stop 
trying.  H0S  provides  automatic  checks  on  the  recall  probabilities  and  the 
user  can  supply  limits  on  the  total  amount  of  time  and  number  of  recall 
attempts  to  be  allowed  to  prevent  such  loops.  If  any  of  these  limits  are 
exceeded,  recall  is  assumed  to  have  failed. 

Although  the  basic  recall  model  described  by  Equation  8  is 
analytically  manageable  for  purposes  of  parameter  estimation,  the  complete 
recall  model  is  not.  Although  it  has  not  been  possible  to  derive  explicit 
expressions  for  the  probability  of  successful  recall  and  amount  of  time 
consumed  in  the  recall  process  under  all  conditions,  reasonable  approxima¬ 
tions  have  bee  ,  obtained  for  the  two  cases  of  most  interest.  These  two 
situations  cc -respond  to  cases  in  which: 

(1)  The  recall  process  is  dominated  by  the  input  variable  d. 

(2)  The  recall  process  is  dominated  by  the  cycle  and  cost  limits. 
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For  both  cases,  it  is  assumed  that  0.1  s  H  <  1.0,  since  the  pre¬ 
dictions  of  the  model  are  obvious  for  other  values  of  these  variables.  In 
this  discussion,  the  following  notations  will  be  used: 

H  =  hab  strength  for  the  item  of  interest. 

t  =  time  since  the  estimated  value  for  the  item  of  interest 
was  last  obtained. 

N  3  min  (cycle  limit,  )  = 

maximum  number  of  micro-attempts  allowed. 

P.j  3  probability  that  recall  succeeds  on  the  ith  micro-attempt. 

q. j  3  probability  that  recall  fails  and  further  micro -attempts  are 

prohibited  after  the  ith  micro-attempt. 

r.  3  probability  that  recall  fails  and  further  micro-attempts  are 

allowed  after  the  ith  micro-attempt. 

P  3  probability  of  eventual  successful  recall. 

Q  3  probability  of  eventual  failure  to  recall. 

R  3  short-term  memory  cycle  time. 

d  =  user-supplied  tolerance  such  that  further  recall  attempts 
will  be  permitted  if  the  random  selected  variable, 

X  >  H  /t . 

C  3  total  time  required  to  obtain  the  estimated  value. 

A  =  time  cost  of  obtaining  the  estimated  value  of  the  item  of 
interest  by  absorption  or  computation. 

S.j  =  time  cost  of  the  recall  process  given  that  it  succeeds  after 
exactly  i  micro-attempts. 

F..  3  time  cost  of  the  recall  process  given  that  it  fails  and 
exits  after  exactly  i  micro-attempts. 

Note  that  some  of  these  variables  represent  constants  and  others 
should  be  considered  as  random  variables.  In  particular,  C,  A,  and  F.  will 
be  treated  as  random  variables.  Our  main  interest  will  be  in  their  respective 
expected  values,  denoted  as  C  3  E (C ) ,  A  3  E(A),  and  FT  =  E(Fi ) . 
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Case  1:  D  Dominated  Model 

In  this  case,  d  is  such  that  the  recall  process  is  terminated  by 

'/x. 

the  random  variable  X  exceeding  H  +  d  •  H.  This  condition  can  be  stated 
expl icitly  as: 


X  -  H 


/t  +  (  i-l )  R 


>  d)  >  0  for  i *  1 ,  2,  ....  N  (10) 


where  X  is  a  random  variable  that  is  uniformaly  distributed  on  the  unit 

interval  and  H  ’/'t  'l'  (i-l)  &  iS  the  probability  of  recall  succeeding  on  the 
.  th 

i  micro-attempt,  given  that  the  process  does  not  terminate  on  an  earlier 


micro-attempt.  For  1  <  H  <  1.0  and  R  >  0,  it  must  be  true  that 
H  *■  >  H  ^  ”  (1*1)  &  for  i  >  Therefore,  for  any  X, 


X  -  H 


ft  *  (i-l)  R 


>  -L for  i-l,  2,  N 


and  Equation  10  may  be  rewritten  as: 


Equation  II  is  satisfied  if  and  only  if  the  condition  within 
the  parenthesis  is  valid  for  X  *  1.  Hence,  our  restriction  on  the  magnitude 
of  d  reduces  to: 


0  s  d  < 


1  -  H 


Clearly,  we  cannot  choose  d  so  that  Equation  12  will  hold  for 
all  admissable  values  of  H  and  t  except  by  choosing  d  =  0,  which  is  not 
interesting,  so  we  must  consider  what  sort  of  constraints  Equation  12 
places  on  H  and  t.  Figure  A-;0  indicates  the  solution  to  this  problem  for 
six  different  values  of  d.  So  long  as  the  point  determined  by  H  and  t 
is  below  the  line  in  the  figure  for  a  given  value  of  d,  then  Equation  12 
will  hold  for  those  values  of  H,  t,  and  d.  Since  hab  strengths  in  HOS 
will  typically  be  in  the  vicinity  of  .9  and  recall  intervals  will  frequently 
be  as  shortasone  to  two  seconds,  d  must  be  approximately  .10  in  order 
for  Equation  12  to  be  valid  and  for  Case  1  to  be  applicable. 

Under  the  assumptions  that  Equation  12  holds,  that  R  is  small  in 
comparison  to  t  and  that  N  is  large,  an  approximation  for  P,  the  probability 
that  the  recall  process  will  ultimately  succeed  can  be  obtained.  The 
probability  of  success,  ,  on  the  i Lh  micro-attempt  at  recall  is  given 
by  the  formula: 


Pi  =  d1*1  •  h1'1  +  A  *  (TT)T 

Thus,  the  probability  of  eventual  successful  recall,  P,  is  the  sum  of 
the  success  probabilities  for  all  possible  micro-attempts. 


P 


N 


2 


d 


i- 1 


H 1 ' 1  *  A  +  (  i-1  )  R 
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yields: 


Invoking  the  assumption  that  R  is  small  in  comparison  to  t 


where  P  is  an  estimate  of  P. 

As  N  ~  *  (i.e.,  if  the  cost  and  cycle  limits  are  removed  from 
the  recall  process)  Equation  13  reduces  to: 


? 


i  -“'"d  “H 


Cl-*) 


The  estimate,  P,  of  P  in  Equation  14  is  actually  without  error 
if  N  =  *  and  R  *  0.  When  these  assumptions  are  not  met,  however,  it  is 
desirable  to  know  how  close  we  can  expect  ?  to  be  to  P.  Under  the  conditions 
that  M  3  ®  and  R  >  C,  it  can  then  be  shown  that  the  accuracy  of  Equation  14, 
as  an  estimate  for  P,  is  constrained  by  the  following  inequality: 


2  (]  -  d  •  H ) 


3  ana 
zero . 


Notice,  in 
‘.he  estimation 


particular,  that  P  will  always  be  an  over-estimate  of 

p 

error  will  aDDroach  zero  as  the  ratio  —  approaches 
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Turning  now  to  the  estimation  of  the  time-cost  of  the  recall 
process  for  Case  1,  we  observe  chat  the  mean  total  time  cost,  C,  for  the 
process  of  obtaining  an  estimated  value  for  an  item  can  be  written  as: 

C  =  PC5  *  ( 1  -  P  )  C £ 


where  the  mean  cime-cost  for  recall  processes  that  succeed  is: 

'■•S','. 


and  the  mean  time-cost  for  recall  processes  that  fail  is: 


and  where 


.V 

C,  =  zl  Q-  F. 

£  i-i  1  1 

=  (i  +  1)  •  R 


is  the  time-cost  of  the  process  if  recall  succeeds  on  the  ith  micro¬ 
attempt  and 


a  *  a 


is  the  mean  time-cost  if  recall  fails  and  the  process  terminates  on  the 
.th 

i  Tncro-attemot. 
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Again,  assuming  that  Equation  12  holds,  that  N  *  «  and  that  t  is  large 
with  respect  to  R,  we  can  obtain  the  following  approximations  for  (Ts  and  C^: 


(IS) 


and 


A 


A 

where  P  is  the  approximation  to  P  given  by  Equation  14. 

It  can  also  be  shown  that,  under  the  above  stated  conditions, 
the  variance,  V$,  of  the  cost  for  successful  recalls  is  approximated  by 
the  formula: 


A 


R2  .  d  .  H 

(i  -  d  -ny 


Case  2:  Recall  Model  Dominated  by  Cost  and  Cycle  Limits 
At  the  opposite  extreme  from  Case  1,  are  situations  In  which  d 
is  sufficiently  large  that  an  additional  micro-attempt  at  recall  is  always 
allowed  after  the  failure  of  one  micro-attempt.  This  condition  can  be 
stated  more  formally  as: 


Pr 


.  H 


>  d 


0  for  i*l. 


*7 

*•  ) 


(16) 
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Assuming  that  Equation  18  holds  and  that  t  Is  large  In  comparison 
to  N  •  R,  then 


P  -  l  -  (l  -  H 


This  is  just  the  probability  that  recall  will  not  fall  on  any  of  N  Independent 
micro-attempts  when  the  probability  of  failure  for  each  micro-attempt  is 
assumed  to  be  1  -  . 

Similarly,  it  can  be  shown  that: 

c  .  »  [1  *  H  -  (  1  -  H  '/r)N  •  (  I  ■  (  N  «  11  H  ^)1 
3  <20) 


Cf  -  N  •  R  ♦  A 


are  adequate  approximations  for  the  time-costs  for  successful  and  unsuc¬ 
cessful  recall  processes. 


..  > 


Experimental  Comparisons 

For  the  purpose  of  comparing  model  predictions  with  experimental 
data,  it  is  necessary  to  identify  the  procedural  features  of  a  memory 
experiment  in  which  either  the  Case  1  or  Case  2  derivations  would  apply. 

Case  1  would  seem  to  apply  to  experiments  for  which  the  subject  is 
encouraged  to  admit  failure  whenever  an  initial  recall  attempt  is  not 
at  least  almost  successful  (the  condition  described  in  Equations  10  through 
12)  and  for  which  a  substantial  time  is  allowed  for  recall  (the  condition 
that  N  -*■  «).  For  Case  2,  a  relevant  experiment  would  be  one  in  which  the 
subject  is  encouraged  to  make  repeated  attempts  at  recall  until  he  succeeds 
or  until  a  time  limit  that  is  small  in  comparison  to  the  retention  interval 
elapsed.  Also,  to  validate  the  models,  experiments  that  employ  numerical 
information  as  the  object  of  recall  are  most  relevant.  In  addition,  the 
experiment  must  include  some  method  for  preventing  the  subject  from  rehears¬ 
ing  the  test  items  during  the  retention  interval. 

Unfortunately,  we  have  failed  to  find  any  short-term  memory  studies 
that  satisfy  these  constraints.  The  primary  problem  is  finding  experiments 
dealing  with  recall  of  numerical  information.  The  only  study  which  we 
located  that  included  such  experiments  was  one  performed  by  Cohen  (1971). 
Unfortunately,  Cohen  did  not  report  response  latencies  and  her  precedures 
cannot  be  characterized  by  either  of  the  two  cases  for  which  we  have  approxi¬ 
mate  performance  predictions  for  the  HOS  model.  (Her  retention  intervals 
were  between  5  and  20  seconds,  while  her  subjects  were  allowed  10  seconds 
to  attempt  to  recall  each  item  and  they  were  encouraged  not  to  stop  trying 
until  the  time  limit  elapsed.)  Me  were  able  to  determine,  however,  that 
the  frequencies  of  correct  recall  obtained  in  Cohen's  experiments  were  gen¬ 
erally  consistent  with  the  basic  recall  function  (P  *  H1^) ,  upon  which  the 
HOS  memory  model  is  based. 

It  is  interesting  to  note  that  the  response  latencies  for  success¬ 
ful  recall  processes  for  the  HOS  model  depend  on  the  retention  interval  in 
both  cases  for  which  time-cost  approximations  were  derived.  Since  that 


dependence  assumes  a  rather  complicated  mathematical  form  (Equations  15  and 
20),  we  have  determined  some  illustrative  empirical  relationships  between 
retention  interval  and  time-cost  for  successful  recall  processes.  Figure 
A-11  portrays  these  results.  The  simulation  that  produced  these  data  modeled 
the  recall  of  consonant  trigrams,  with  each  trigram  being  treated  as  three 
separate  items.  It  seems  somewhat  surprising  that  response  latency  in  the 
figure  is  virtually  constant  over  a  large  range  of  retention  intervals.  This 
observation  is  consistent  with  the  claim  of  Waugh  (1969)  that,  for  verbal 
material,  the  mean  latency  of  successful  recall  from  short-term  memory,  is 
independent  of  retention  Interval.  Some  further  simulation  results  for  the 
same  consonant  trigram  memory  model  are  presented  in  Figure  A-12,  together 
with  some  experimental  data.  Note  that  an  optimal  fit  to  the  results  of 
Peterson  and  Peterson  (1959)  and  Murdock  (1961)  is  achieved  when  the  param¬ 
eter  REMEM  is  set  to  .07.  Since  these  data  Inspired  the  basic  function  for 
recall  upon  which  the  HOS  memory  model  Is  based.  It  Is  reassuring  to  note 
that  the  elaborated  model  continues  to  fit  the  same  data.  We  imaging  that 
the  disparate  results  of  Melton,  Crowder,  and  Wulff  (1963),  also  displayed 
in  Figure  A-12,  are  a  consequence  of  factors  in  their  experiment  which 
allowed  their  subjects  to  comnit  the  test  Items  to  long-term  memory. 
Accordingly,  we  are  not  particularly  concerned  with  the  failure  of  any  of 
our  HOS  simulations  to  mimic  those  results. 
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A  BRIEF  HISTORICAL  PERSPECTIVE  OF  HOS 
(1967-1978) 

Robert  J.  Wherry,  Jr.,  PhD. 

It  is  a  truism  that  necessity  is  often  the  mother  of  invention  — 
and  this  is  certainly  true  with  regard  to  HOS.  It  was  conceived  out  of 
feelings  of  frustration  and  disappointments  with  the  impotency  of  human 
engineering  technology  of  the  mid-Sixties.  The  concept  of  a  Human  Operator 
Simulator  (HOS)  did  not  Suddenly  appear  to  me  one  day,  but  was,  I  believe, 
the  inevitable  outcome  of  consciously  searching  for  a  better  approach  to 
solving  human  engineering  problems.  The  concept  of  modeling  human  behavior 
had  attracted  me  for  a  number  of  years,  however,  prior  to  those  months  in 
1967  when  HOS  was  ultimately  conceived.  I  am  certain  that  the  prior  work 
with  which  I  had  been  involved  in  the  area  of  vigilance  behavior,  informa¬ 
tion  processing  under  stressful  conditions,  and  predictions  of  student 
pilot  success  or  failure  were  instrumental  in  directing  the  ultimate  con¬ 
ception  of  how  humans  processed  information  and  did  various  tasks.  Factor 
analytic  studies  I  had  done  In  Pensacola,  Florida  on  a  rather  wide  variety 
of  pilot  tasks  had  left  on  me  an  Indelible  appreciation  (or  belief,  at  any 
rate)  that,  perhaps,  only  a  few  independent  factors  really  accounted  for 
goodness  of  performance  in  what,  at  first,  had  appeared  to  be  very  diverse 
tasks.  Finally,  the  experience  which  I  had  gained  since  1959  in  programming 
computers  for  comp1 ex  applications  in  aviation  psychology,  medicine,  and 
biophysics  had  made  a  believer  of  me  with  regard  to  the  potential  power 
of  computer  simulation  for  solving  all  sorts  of  problems. 


Thus,  HOS  not  only  developed  from  d  specific  need,  but  it  also 
grew  out  of  what  I  consider  to  be  an  unusual  and  fortuitous  series  of  experi¬ 
ences  to  which  I  had  been  exposed.  To  better  appreciate  the  specific  purposes 
for  which  HOS  was  Initially  conceived  and  developed,  I  must  take  you  back 
to  late  1966  when  I  was  transferred  from  Pensacola,  Florida. to  the  Naval 
Missile  Center  (NMC)  at  Point  Mugu,  California  to  head  up  the  human  engineer¬ 
ing  branch.  Our  mission  there  was  to  accomplish  the  tests  and  evaluations 
of  new  Naval  airborne  weapons  systems. 

To  perform  a  test  and  evaluation  one  must,  of  course,  first 
decide  what  one  desires  to  test.  It  became  obvious  that  two  different 
approaches  were  possible.  The  first  I  shall  refer  to  as  "comparison  with 
specs  and  standards"  and  the  second  I  shall  call  "performance  evaluation." 

The  first  approach  dealt  with  testing  whether  various  aircraft  displays, 
controls,  labels,  panels,  etc.,  conformed  to  Human  Engineering  guides, 
standards  and  specifications.  It  may  be  recalled  that  MIL  STD  1472 
and  MIL  SPEC  46855  were  first  issued  In  1966.  Because  of  this  we  had  in  our 
possession,  at  that  time,  the  latest  documents  containing  data  on  what  the 
Navy  (and  the  other  services  as  well)  deemed  to  be  "acceptable"  HE  design 
standards.  On  the  other  hand,  because  of  the  newness  of  those  documents, 
no  system  arriving  for  test  and  evaluation  at  NMC  for  several  years  there¬ 
after  would  have  required  a  contractor  to  meet  those  standards  and  specifica¬ 
tions.  Thus,  those  documents  did  offer  a  standard  of  comparison  by  which 
at  least  some  aspects  of  the  crewstations  could  be  evaluated  even  though 
it  might  be  difficult  or  Impossible  to  force  an  air  frame  contractor 
comply  with  those  standards.  A  second  drawback  in  using  MIL  STD  1472  was 
that  no  guidance  on  the  impact  on  operator  or  system  performance  was  pro¬ 
vided  in  cases  where  various  aspects  of  crewstation  design  failed  to  meet 
the  new  standards.  I  found  that  it  was  virtually  Impossible  to  get  the 
Navy  interested  in  correcting  any  single  deficiency,  because  no  single 
deficiency  was  ever  so  bad  as  to  be  able  to  say  that  it  alone  made  the  air¬ 
craft  either  unsafe  or  that  it  alone  would  be  the  cause  of  unsuccessful  or 
aborted  mission  performance.  It  was  obvious  to  our  human  engineering  team 


that  the  cumulative  effect  of  a  series  of  minor  deficiencies  could  and  would 
have  a  major  impact  on  system  safety  and  mission  success.  To  be  able  to 
convince  others  of  this  point  of  view,  however,  would  require  a  fairly 
detailed  model  of  the  impact  of  various  display  and  control  features  on 
human  information  absorption,  processing,  and  transmission  in  a  task  sequenc¬ 
ing  framework  to  illustrate  such  cumulative  effects!  Unfortunately,  such 
models  were  not  available  at  that  time. 

The  second  approach  to  the  test  and  evaluation  of  the  crewstation 
dealt  with  attempting  to  determine  (regardless  of  conformance  or  non-con¬ 
formance  to  various  MIL  STDs)  If  the  operators  were  able  to  adequately  per¬ 
form  the  various  functions  which  had  been  allocated  to  them.  In  attempting 
to  determine  precisely  what  was  expected  of  a  given  operator,  we  had  occa¬ 
sion  to  examine  a  wide  variety  of  task  analyses  and  timelines  which  had  been 
prepared  by  a  variety  of  different  contractors.  Without  exception,  these 
rather  costly  items,  when  they  had,  in  fact,  been  prepared,  were  extremely 
disappointing  in  terms  of  adequately  expressing  what  was  actually  expected 
of  a  given  operator.  All  too  often  task  analysis  blocks  had  been  prepared 
at  a  very  macro  level  (e.g.,  "Pilot  acquires  and  locks  on  target")  and  times 
assigned  to  such  activities  were, obviously,  merely  "educated  guesses."  It 
was  my  personal  experience  that,  at  least  by  the  time  a  weapon  system  was 
delivered  to  NMC,  no  task  analysis  or  timeline  indicated  that  the  operator 
would  be  too  busy  to  perform  all  the  functions  he  had  been  assigned.  The 
task  analyses  which  we  reviewed  in  those  days  also  failed  to  give  the 
reader  a  good  appreciation  of  the  often  necessary  simultaneity  of  various 
different  task  demands  facing  a  particular  operator  during  crucial  segments 
of  a  mission.  It  became  obvious  that  a  more  stringent  set  of  rules  were 
needed  in  guiding  whoever  prepared  task  analyses  so  that  (a)  an  appropriate 
level  of  detail  would  be  included,  and  (b)  a  given  statement  made  by  a  task 
analyst  could  be  interpreted  without  ambiguity  as  to  what  the  operator's 
responsibilities  were.  (From  this  concept,  the  Human  Operator  Procedures 
(HOPROC)  language  ultimately  arose.)  Further,  it  was  felt  that  a  successful 
accomplishment  of  any  task  analysis  really  Involved  two  distinct  efforts. 
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the  first  of  which  was  expressing  what  was  expected  of  the  operator  (in 
terms  of  what  actions  he  must  take)  and  the  second  was  (given  the  displays, 
controls,  and  layout  of  the  crewstation)  to  determine  If  the  operator  could, 
in  fact,  accomplish  all  those  assigned  tasks  within  the  requisite  time. 

This  implied  that  the  tasks  themselves  ought  to  be  able  to  be  described 
independently  of  the  particular  crewstation  layout,  and,  if  a  sophisticated 
human  pevfomanoe  nodal  uieTa  available,  then  the  impact  of  different  crew¬ 
station  designs  could  be  reliably  and  objectively  evaluated  without  relying 
on  "educated  guesses"  by  contractor  personnel  who  had  a  personal  interest 
in  making  their  own  aircraft  appear  to  be  good  in  the  Navy’s  eyes. 

In  a  very  real  sense,  the  first  concept  of  HOS  was  never  intended 
to  simulate  all  types  of  human  performance,  but  it  did  set  out  to  quantify 
performance  times  of  various  types  of  anatomy  movement  (head  and  eyes,  hands 
and  arms,  feet,  etc.)  and  the  effect  of  various  features  of  displays  and 
controls  (e.g.,  size,  contrast,  shape,  etc.).  Actually,  my  own  feeling  by 
late  1967,  was  that  we  were  a  long  way  from  being  able  to  predict  the  times 
various  mediated  mental  processes  might  take,  but  that  at  least  those 
observable  events,  such  as  anatomy  movements,  absorption  of  information  from 
displays,  and  manipulation  of  controls,  should  be  able  to  be  accurately 
predicted.  In  this  respect,  I  was  especially  encouraged  by  the  work  of 
Topmlller  and  Sharp  (1965)  which  had  indicated  that  arm-hand  reach  time  was 
very  predictable.  Also  several  Informal  studies  (which,  I  deeply  regret, have 
never  been  published)  on  eye  movement  and  fixation  times  and  on  numeral  and 
dial  reading  times  which  were  conducted  by  Alvah  Bittner  and  myself  at  Pt,  Mugu 
that  greatly  supported  the  concept  that  any  task  could  be  broken  down  into 
sequences  of  various  "micro"  processes  and  the  sum  of  the  micro  process  times 
would,  in  fact,  yield  the  total  task  times,  Many  people  rejected  such  a 
hypothesis  and  predicted  that  there  would  be  tremendous  interactions  among 
many  if  not  all  of  the  micro  processes  which  would  make  the  analytical 
"additive"  approach  I  was  advocating  doomed  to  failure.  Such  discussions 
and  arguments,  I  might  add,  were  very  philosophical,  since  neither  I  nor 
my  opponents  had  sufficient  data  to  support  our  contentions  in  those  days. 
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I  suppose  I  stuck  with  the  belief  that  each  micro  process  was  independent 
primarily  because,  if  it  turned  out  not  to  be  true,  there  would  be  little 
hope  for  a  “scientific"  approach  to  human  engineering  in  the,  then,  fore¬ 
seeable  future. 

In  addition  to  the  above-mentioned  reasons  for  the  development  of 
a  HOS,  there  was  yet  another  reason.  In  those  days,  we  were  conducting  some 
open-loop  simulations  of  various  missile  and  missile  launch  systems.  In 
one  conducted  by  Chuck  Hutchins,  it  was  discovered  that  operators  in  the 
laboratory  simulation  were  getting  very  good  scores  on  locking  onto  and 
4aunching  a  simulated  missile  at  a  simulated  target.  It  was  also  discovered 
that  the  operators  were  waiting  until  minimum  range  to  launch  their  simulated 
weapons.  The  simulated  targets  were  capable  of  maneuvering,  but  the 
maneuvers  were  “canned"  and  had  nothing  to  do  with  the  maneuvering  our 
pilots  were  doing.  Further,  the  simulated  targets  never  fired  back,  which 
might  well  account  for  the  willingness  of  our  pilots  to  wait  until  minimum 
range  to  release  their  missiles.  Thus,  the  concept  of  a  simulated  human 
operator  to  be  used  as  an  intelligent  adversary  was  also  one  of  the  original 
planned  uses  of  a  HOS  (although,  to  date,  HOS  has  never  been  used  for  this 
purpose) . 


In  formulating  the  philosophy  of  how  one  could  simulate  a  human 
operator's  behavior,  one  major  concern  I  had  in  1967  was  whether  a  human 
being  could  be  considered  to  be  a  discrete  or  continous  information  processor. 
In  those  days,  many  people  held  to  the  concept  that  man  was  indeed  a  con¬ 
tinuous  processor.  If  this  were  true,  it  might  be  more  appropriate  to  use 
an  analog  rather  than  a  digital  computer.  However,  by  reanalyzing  some  data 
collected  much  earlier  by  John  Senders,  I  came  to  the  conclusion  that  even 
in  a  continuous  tracking  task,  the  human  appeared  to  be  sampling  the  avail¬ 
able  displayed  information  only  about  13  times  per  second.  Thus,  man 
appeared,  at  least  to  me,  not  to  be  a  continuous  sampler,  but  a  discrete 
one  who  could  relatively  easily  be  simulated  with  a  digital  computer. 
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Another  major  philosophical  point  was  whether  man  should  be  con¬ 
sidered  to  be  a  single-  or  multi-channel  processor.  This  is  more  than  a 
question  of  whether  an  operator  can  be  responsible  for  carrying  out  more  than 
one  task  at  a  time,  for  this  he  might  appear  to  do  even  if  he  were  a  single¬ 
channel  operator  capable  of  very  rapid  interlacing  among  more  than  one  task. 

The  single-channel  vs.  multi-channel  question  really  revolves  on  the  issue 
of  whether  the  operator  can  3zmuZt<maoualy  be  thinking  about  two  different 
things.  After  much  introspection  (as  well  as  considering  the  writings  of 
various  experts  on  this  question)  I  chose  essentially  to  conceive  of  man 
as  being  a  single-channel  processor  who  is  capable  of  rapidly  multiplexing 
among  several  tasks. 

This,  in  turn,  led  to  the  concept  in  HOS  of  permitting  the 
simulated  operator  to  have  many  different  procedures  going  on  at  the  same 
time.  In  HOS,  we  call  these  the  "active"  procedures,  while  those  which  are 
not  currently  of  concern  to  the  operator  are  known  as  "inactive"  ones. 

However,  while  many  tasks  may  be  "active,"  HOS  only  works  on  one  at  a  time. 

One  of  the  earliest  studies  I  did  (.long  before  HOS  or  the  HOPROC 
language  existed)  was  a  relatively  simple  computer  simulation  to  determine 
what  would  happen  under  various  strategy  algorithms  for  deciding  which  dis- 
olays  to  pay  attention  to  when  the  simulated  operator  was  responsible  for 
monitoring  several  different  ones  at  the  same  time.  These  early  studies  led 
to  the  concepts  of  a  MONITORING  PROCEDURE  for  a  display  as  well  as  the  concepts 
of  a  procedure's  "CRITICALITY"  and  the  idea  that  criticality  could  dynamic¬ 
ally  change  as  a  function  of  the  disparity  between  a  display's  "desired 
position,"  its  "allowable  limits",  and  its  "estimated  position."  These  con¬ 
cepts  have  been  retained  in  HOS  since  its  beginning  stages  back  in  early 
1968.  Such  algorithms  provide  the  basis  for  the  "adaptiveness"  of  the 
behavior  exhibited  by  HOS. 
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Another  very  early  consideration  (which  has  changed  very  little 
over  the  years)  was  how  to  handle  "short-term"  memory  of  the  simulated 
operator.  The  concept  of  "HA8"  strength  (which  is  discussed  elsewhere) 
and  the  probability  of  successful  recall  of  an  item  of  information  which 
had  been  recently  absorbed  was  a  concept  which  I  adapted  from  Hull's  and 
Thorndike’s  theories  of  learning.  The  concept  of  modeling  short-term  memory 
was  felt  to  be  necessary  to  determine  how  often  the  human  would  feel  a 
necessity  to  update  his  current  information  about  some  parameter  by  actually 
looking  at  a  display. 

By  1968,  the  basic  concepts  of  HOS  which  included  micro-process 
handlers,  adaptiveness  algorithms,  short-term  memory,  with  the  operator  as 
a  single-channel  processor  capable  of  rapid  multiplexing  among  the  "active" 
procedures  had  been  formulated  in  detail  as  well  as  the  earliest  version 
of  the  HOPROC  language  by  which  the  user  would  specify  what  it  was  that  the 
simulated  operator  was  expected  to  do.  These  concepts  were  reported  in  the 
proceedings  of  a  two-day  meeting  jointly  hosted  by  the  Office  of  Naval 
Research  and  North  American  Aviation  in  Columbus,  Ohio  in  November,  1968. 

It  is  surprising  and  somewhat  rewarding  to  see  how  little  the  basic  concepts 
formulated  10  years  ago  have  changed  during  its  development.  It  is  also 
interesting  to  note  that  I  and  other  participants  at  that  meeting  estimated 
that  it  might  take  10  years  to  develop  HOS. 

By  1969,  I  was  able  to  get  some  Independent  Research  (6.1)  funds 
to  pay  for  a  programmer  (Mr.  Don  Kennerly  —  then  a  member  of  our  HE  branch) 
to  start  programming  both  the  earliest  versions  of  HOS  and  HAL  (the  HOPROC 
Assembler/Loader  program  which  was  to  decipher  the  HOPROC  statements  for 
input  to  the  HOS  program).  These  earliest  programs  did  not  include  all  the 
specifications  of  HOS  mentioned  above  and  HAL  was  written  in  COBOL.  More  than 
anything  else,  they  proved,  at  least  to  my  own  satisfaction,  that  it  would 
be  feasible  to  write  a  digital  computer  program  for  a  full-blown  HOS.  It 
was  also  in  1969  that  Bittner  and  I  did  the  experiments  mentioned  above  which 
also  were  very  encouraging  regarding  the  concept  of  the  additivity  of  micro¬ 
process  times. 
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In  August  of  1970,  I  mss  transferred  to  the  Naval  Air  Development 
Center  in  Warminster,  Pennsylvania  and  it  was  immediately  obvious  that  a  HOS 
would  be  even  more  valuable  during  early  system  development  than  during 
later  test  and  evaluation  phases  of  system  design. 

Paul  Chatelier,  who  was  at  that  time  stationed  at  NADC,  was  in 
the  throes  of  formulating  CAFES  which  also  dealt  with  computerized 
approaches  to  improving  human  factors  engineering  technology.  (Later  fund¬ 
ing  for  HOS  was  formally  included  in  the  CAFES  program  element  number,  but 
for  two  years  they  stayed  as  separate  development  efforts.) 

8y  December,  1970  ,  Analytics  became  interested  in  the  HOS  concept 
and  submitted  a  proposal  to  work  on  its  further  development.  Prior  to 
that,  I  had  discovered  that  although  I  had  brought  the  HOS  and  HAL  programs 
(written  by  Kennerly)  with  me,  NAOC  did  not  have  a  version  of  COBOL  which 
could  compile  the  HAL  program  as  it  then  existed.  It  was  decided  that  it 
would  be  better  to  have  all  the  future  programs  written  in  FORTRAN  for  sub¬ 
sequent  ease  in  transferring  them  about  the  country. 

The  first  contract  to  Analytics  for  work  on  HOS  was  let  in  1971  and 
out  of  that  effort  what  I  might  call  HOS  II  and  HAL  II  were  developed.  It 
is  interesting  to  note  that  none  of  the  original  Analytics  team  which  started 
with  that  project  are  any  longer  involved  with  the  work  Analytics  has  done 
in  the  past  six  years  on  the  HOS  project. 

As  more  work  was  accomplished  on  HOS,  it  became  obvious  that 
various  additional  statements  in  the  HOPROC  lam/gage  would  be  desirable  as 
well  as  a  greater  flexibility  in  how  one  could  express  various  statements. 

For  a  while,  these  additions  were  added  as  patches  to  the  program  until  it 
became  obvious  that  it  was  time  to  go  back  and  incorporate  all  these  changes 
as  well  as  some  additional  new  concepts  into  the  HAL  and  HOS  programs.  Thus, 
what  has  been  available  since  late  1975  actually  is  what  we  might  call  HOS  III 
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and  HAL  III.  Since  that  time,  we  have  almost  exclusively  been  involved  in 
validity  testing  of  HOS  III  and  little  or  no  additional  development  has 
taken  place. 

This  does  not  mean  to  imply  that  HOS  is  considered  to  be  in  its 
final  or  ultimate  stage  of  development,  for  there  are  many  additional  features 
which  should  and  could  be  added  to  HOS.  However,  HOS  III  does  represent 
what  I  consider  to  be  a  highly  useful  technique  for  the  initial  assessment 
of  how  well  a  trained  operator  will  be  able  to  perform  his  tasks  in  a 
specified  crewstation  under  varying  situational  demands. 

One  concept  which  was  definitely  added  to  HOS  in  1974  which  was 
a  rather  marked  departure  from  original  plans  for  HOS,  was  the  concept  of 
simulating  the  system  hardware  and  software  as  well  as  targets  using  the 
HOPROC  language  and  the  HAL  and  HOS  programs.  Originally,  HOS  was  only  to 
be  the  Human  Operator  Simulator  and  it  was  anticipated  that  it  would  be 
interfaced  to  hardware  simulators  in  some  fashion.  It  was  found,  however, 
that  it  would  be  extremely  difficult  to  modify  hardware  simulators  written 
by  others  so  that  HOS  could  easily  interface  with  them.  After  much  soul 
searching,  it  was  decided  to  expand  the  HOPROC  language,  HAL  and  HOS,  to 
include  the  ability  to  simulate  hardware  as  well  as  the  human  components. 

These  changes  were  also  incorporated  and  indeed  necessitated  the  rewriting 
for  HOS  III  and  HAL  III. 

The  concept  of  a  HOOAC  (Human  Operator  Data  Analyzer/Collator) 
program  to  analyze  the  human  operator  data  emminating  from  a  HOS  run  was 
included  in  the  very  early  stages  of  HOS  planning.  The  first  HODAC,  how¬ 
ever,  was  not  available  until  1974.  It  has  proven  to  be  less  useful  than 
I  originally  thought  it  might,  but  this  may  be  due,  in  part,  to  the  fact 
that  we  have  to  date  been  most  interested  in  seeing  if  HOS  behaves  like 
real  operators  in  systems  which  have  already  actually  been  built  (i.e.,  our 
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validating  studies)  rather  than  in  systems  which  are  actually  under  development. 
It  may  be  that  many  of  the  routines  available  in  HOOAC  will  turn  out  to  be 
very  useful  in  deciding  potential  changes  to  procedures  and  crewstatlon 
design  when  we  try  HOS  on  a  developing  systems  and  we  determine  that  unless 
something  is  changed,  it  will  be  impossible  for  the  operator  to  successfully 
do  all  his  allocated  functions. 

While  HAL  III  and  HOS  III  both  now  contain  the  additional  capa- 
bllity  for  simulating  hardware  and  target  systems,  there  Is  no  automatic 
logging  of  their  behavior  as  there  is  with  the  simulated  human  behavior. 

Hi  part,  this  is  due  to  the  fact  that  HOS  does  not  contain  a  "general 
purpose"  hardware  system  model  which  1$  made  system  specific  by  the  hard* 
ware  procedures  and  hardware  functions.  Lacking  an  overall  scheme  for  a 
general  hardware  system  means  that  hardware  systems  are  not  automatically 
reducible  to  a  specified  number  of  micro-processors  which  can  then  be  auto¬ 
matically  logged  out  whenever  they  are  used.  This  necessitates  some  amount 
of  cleverness  on  the  part  of  the  HOS  user  to  either  log  out  and/or  accumulate 
data  of  Interest  to  overall  systw  performance. 

Earlier,  I  mentioned  that  HOS  should  not  be  considered  to  be  fully 
developed.  Areas  where  HOS  might  be  expanded  Include  the  addition  of  a 
"fatigue"  model,  the  capability  to  pick  up  and  move  objects  from  one  place 
to  another,  the  capability  to  walk  (or  run)  from  one  place  to  another,  the 
ability  to  talk  to  another  operator,  the  capability  to  perform  visual  target 
recognition  In  a  complex  visual  field,  etc.  I  am  convinced  that  each  of 
the  above  concepts  can  be  added  to  HOS  and  I  have,  at  least,  rudimentary 
models  or  schemes  for  handling  all  of  the  above  concepts  as  well  as  several 
others.  With  the  rather  successful  validation  studies  which  have  been  con¬ 
ducted  on  HOS  III,  it  Is  probably  now  time  to  start  the  development  of  HOS 
IV  and  HOS  V  which  would  be  versions  to  Include  one  or  more  of  the  above 
concepts. 
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Finally,  I  would  be  remiss  if  I  did  not  discuss  the  concept  of 
operator  error  as  it  is  treated  in  HOS.  More  than  any  other  single  Item, 
the  way  operator  error  is  treated  in  HOS  has  been  criticized.  With  a 
few  exceptions  (which  are  discussed  elsewhere),  HOS  does  not  make  errors. 
Some  people  claim  that  this  Is  unrealistic,  but  I  maintain  that  as  long  as 
the  human  operator  is  given  the  requisite  amount  of  time  to  do  a  task,  then 
he  does  not  make  errors.  He  may  not  finish  all  the  tasks  we  would  like 
him  to  do,  and  he  may  not  do  them  as  well  as  we  would  like  him  to  do  them, 
but  as  long  as  he  works  at  a  reasonable  pace,  he  will  not  make  an  error. 

The  fact  that  he  doesn't  get  all  his  tasks  accomplished  when  he  works  at 
a  reasonable  pace  merely  Indicates  that  we  allocated  too  many  tasks  to 
him.  Thus,  if  HOS  indicates  the  simulated  operator  spends  too  little 
time  on  a  given  task,  we  may  either  assign  a  higher  criticality  to  that 
task  and  rerun  the  simulation  to  see  if  this  alleviates  the  problem,  or 
we  may  reduce  the  number  of  tasks  which  were  originally  allocated  to  the 
operator  to  see  if  this  solves  the  problem. 

I  am  certain  that  real  systems  do  exist  in  which  operators  make 
mistakes.  On  the  other  hand,  this  is  a  clear  indication  that  we  have, 
in  those  systems,  asked  the  operator  to  do  too  many  and/or  too  complicated 
tasks  and  therefore  those  systems  are  not  properly  human  engineered  by 
definition,  since  successful  performance  of  the  tasks  are  not  within  the 
capabilities  of  the  operator.  What  HOS  does  is  essentially  to  "Instruct" 
the  operator  not  to  attempt  to  work  at  a  pace  at  which  errors  and  mistakes 
will  occur  because  we  hold  to  the  concept  that  errors  are  the  result  of 
being  under  time  stress  and  that  error-free  performance  can  be  maintained 
provided  the  operator  does  not  attempt  to  do  too  many  things  in  too  short 
of  a  time  period.  The  human  errors  that  are  observed  in  existing  systems 
are  the  result  of  real  operators  attempting,  unsuccessfully,  to  perform 
at  a  higher  level  than  their  capabilities  permit. 


297 


In  closing  this  brief  historical  perspective,  I  should  also 
mention  that  working  on  the  development  of  HOS  has  been  both  fun  and 
exciting.  The  associations  I  have  formed  with  the  many  people  who  have  parti¬ 
cipated  In  this  development  program  has  been  very  rewarding  professionally 
over  the  years.  Finally,  working  on  HOS  has  also  often  been  a  humbling 
proposition  as  we  have  discovered  how  little  we  actually  know  about  how 
humans  behave. 
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